Gitea Docker flaw turns a trusted proxy header into account takeover

Gitea Docker flaw turns a trusted proxy header into account takeover

Gitea has fixed a critical authentication bypass in its official Docker images that could let an unauthenticated client impersonate any known user by sending a single reverse-proxy identity header. The flaw is tracked as CVE-2026-20896 and carries a CVSS 3.1 score of 9.8.

The bug is narrow in configuration but serious in impact. It affects Gitea Docker images up to and including 1.26.2 when reverse-proxy authentication is enabled and the backend Gitea service can be reached by something other than the intended authenticating proxy. Under those conditions, a client can send X-WEBAUTH-USER with a valid username and Gitea may treat that client as the named user.

That makes this more than a normal login bug. Gitea is a self-hosted code collaboration platform. A successful account takeover can expose source code, private repositories, package registry data, webhooks, CI/CD configuration, deployment keys, access tokens, and secrets accidentally committed by developers.

What went wrong

Reverse-proxy authentication is a common enterprise pattern. A trusted proxy, SSO gateway, or identity-aware access layer authenticates the user first, then forwards the authenticated identity to the backend application in a header. The backend should only accept that identity header from the trusted proxy.

In vulnerable Gitea Docker images, the bundled app.ini template hard-coded:

textCopy
REVERSE_PROXY_TRUSTED_PROXIES = *

The documented safe default is loopback-only: 127.0.0.0/8,::1/128. The wildcard value effectively means "trust identity headers from every source IP." If an administrator enabled ENABLE_REVERSE_PROXY_AUTHENTICATION = true and left the Docker image's trusted-proxy setting in place, any source that could reach the Gitea HTTP port could present a username using X-WEBAUTH-USER.

The official advisory says binary and self-built deployments that follow app.example.ini receive the loopback-only default and are not affected in the same way. The risky deployment shape is specifically the official Docker image behavior combined with reverse-proxy authentication and reachable backend traffic.

Why reachable backend ports matter

The identity header is not magic. Any HTTP client can send custom headers. The security model depends on network path control: users should reach the proxy, the proxy should reach Gitea, and Gitea should reject identity headers from anywhere else.

CVE-2026-20896 breaks that trust boundary when the backend service accepts proxy identity headers from all sources. If an internet-facing or internally reachable Gitea container can be accessed directly, an attacker may not need a password, token, or session cookie. A known or guessable username can be enough.

Administrator accounts are the obvious target. If reverse-proxy auto-registration is also enabled, the exposure may be worse because the same primitive can create accounts with chosen usernames. Even without administrator impersonation, access to a developer account can be enough to read private repositories, modify code, tamper with automation, or harvest secrets.

Attack activity is already being reported

The vulnerability was disclosed in late June and fixed in Gitea 1.26.3. Gitea followed quickly with 1.26.4, which the project recommends as the direct upgrade target because it includes a regression fix and another security fix.

Public reporting citing Sysdig says probing was observed 13 days after disclosure, with the activity described as early investigation rather than a mature campaign at the time of reporting. That still matters. Header-based authentication bypasses are simple to test at scale, and self-hosted developer platforms are attractive because they often sit near source code, deployment workflows, and internal credentials.

This is the moment for defenders to verify configuration, not wait for a confirmed breach report.

Who is exposed

The highest-risk deployments have all of these conditions:

• official gitea/gitea Docker image version 1.26.2 or earlier
• reverse-proxy authentication enabled
• effective REVERSE_PROXY_TRUSTED_PROXIES set to * or another overly broad range
• the Gitea HTTP port reachable directly by an untrusted external client, internal host, container, VPN user, or workload
• valid or guessable usernames, especially administrator usernames

The vulnerability should not be framed as "every Gitea instance is compromised." A deployment with reverse-proxy authentication disabled is not using this login path. A backend reachable only from the real proxy has a stronger network control. A non-Docker build following the documented loopback-only default is a different exposure case.

But those distinctions should be verified, not assumed. Many Docker deployments expose service ports for convenience during setup, then keep the same topology in production.

What defenders should do now

First, upgrade Gitea Docker deployments to 1.26.4 or later. Version 1.26.3 fixes CVE-2026-20896, but Gitea recommends moving directly to 1.26.4.

Second, inspect the effective configuration after the container restarts. Confirm that reverse-proxy authentication is only enabled where it is intentionally needed, and that REVERSE_PROXY_TRUSTED_PROXIES contains only the real proxy address ranges. Do not rely on an image tag alone.

Third, block direct access to the Gitea backend port. Only the authenticating proxy should be able to reach the application service. Apply firewall rules, container network controls, Kubernetes NetworkPolicies, security groups, or service mesh policy depending on the deployment environment.

Fourth, strip identity headers at the edge. The public-facing proxy should remove inbound X-WEBAUTH-USER and related authentication headers from client requests before it sets its own trusted identity headers. This reduces the chance that a misrouted request carries attacker-controlled identity metadata downstream.

Fifth, review logs. Look for unusual requests containing X-WEBAUTH-USER, unexpected direct access to Gitea's HTTP service, new sessions for administrative usernames, repository access spikes, unexplained token or key creation, webhook changes, and CI/CD workflow edits.

Incident response considerations

If logs suggest exploitation, treat the case as more than a web session incident. Gitea can hold the materials attackers need for software supply chain compromise.

Response should include:

• revoke suspicious sessions and personal access tokens
• rotate deploy keys, webhook secrets, CI/CD credentials, package registry tokens, and integration tokens
• review recent repository commits, protected branch changes, releases, packages, and pull requests
• audit new users, changed permissions, OAuth applications, SSH keys, and runner registrations
• search private repositories for exposed credentials that may have been accessed
• verify build and deployment pipelines before trusting new artifacts

This is where incident response needs to meet DevSecOps reality. If attackers gained code-hosting access, the blast radius may include downstream builds, cloud credentials, production deployments, and customer-facing packages.

The larger lesson

Reverse-proxy authentication is only as strong as its trust boundary. The backend application must know exactly which proxy is allowed to assert identity, and the network must prevent clients from bypassing that proxy.

CVE-2026-20896 is a sharp reminder that defaults inside container images are part of the security model. A single wildcard in a trusted-proxy list can turn a clean authentication architecture into a one-header vulnerability.

For security teams, the practical takeaway is simple: inventory self-hosted developer platforms, validate proxy-auth settings, and make backend reachability a first-class control. Source code systems are not ordinary web apps. When they fail, the impact can spread through the build pipeline.

What is CVE-2026-20896?

CVE-2026-20896 is a critical Gitea Docker authentication bypass caused by official Docker images trusting reverse-proxy identity headers from any source IP when reverse-proxy authentication is enabled.

Which versions are affected?

The Gitea advisory lists official Docker images up to and including 1.26.2 as affected. 1.26.3 is the patched version for this issue, and Gitea recommends upgrading directly to 1.26.4.

Is every Gitea deployment vulnerable?

No. The highest-risk condition requires the affected Docker image, reverse-proxy authentication, overly broad trusted-proxy configuration, and reachability of the backend Gitea HTTP port by an untrusted source.

What should teams check first?

Check the running image version, whether ENABLE_REVERSE_PROXY_AUTHENTICATION is enabled, the effective value of REVERSE_PROXY_TRUSTED_PROXIES, and whether anything except the intended proxy can reach the Gitea backend port.

References

1. Gitea Docker image: REVERSE_PROXY_TRUSTED_PROXIES = * default lets any source IP impersonate any user via X-WEBAUTH-USER
2. Gitea 1.26.3 and 1.26.4 are released
3. CVE-2026-20896 CVE Record
4. Threat Actors Probe Gitea Docker Flaw CVE-2026-20896 13 Days After Disclosure
5. Critical Gitea Docker Bug Under Active Exploitation Exposes Repositories and Secrets