- What: CVE-2026-20896, a critical authentication bypass in the default configuration of official Gitea Docker images through 1.26.2, is under active exploitation via spoofed X-WEBAUTH-USER reverse-proxy headers.
- Impact: Attackers can impersonate any user, including administrators, with no password or token, giving them full control of source code, CI secrets, and everything downstream of the compromised Git server.
- Fix / mitigation: Upgrade to Gitea 1.26.4 (1.26.3 fixed the flaw but introduced a regression) and lock REVERSE_PROXY_TRUSTED_PROXIES to explicit trusted IPs instead of a wildcard.
- Who's at risk: Anyone running the official Gitea Docker image, especially the roughly 6,200 instances reachable from the public internet, and any org whose CI/CD pipeline trusts that Gitea as a source of truth.
No password. No token. One header. That is the entire exploitation story for CVE-2026-20896, a critical authentication bypass in the official Gitea Docker images that attackers began exploiting in the wild just 13 days after the advisory went public. If you run Gitea from the official container image at version 1.26.2 or earlier, an unauthenticated attacker who can reach your instance may be able to log in as any user on the system, including your administrators, by adding a single HTTP header to their request.
The exposure is not theoretical. Roughly 6,200 Gitea instances are reachable on the public internet right now. Not all of them are confirmed vulnerable, but scanning is already underway: Sysdig security researcher Michael Clark observed a VPN-exit scanner probing specifically for this flaw, and Singapore's Cybersecurity Agency has issued its own alert urging immediate patching.
The flaw: trusting a header anyone can send
Gitea, like many self-hosted services, supports reverse-proxy authentication. In that model, an upstream proxy such as nginx or an SSO gateway authenticates the user, then forwards the request to Gitea with an identity header, X-WEBAUTH-USER, telling Gitea who the user is. Gitea trusts that header and creates a session for the named account. The whole scheme depends on one assumption: only the trusted proxy can set that header.
In the affected Docker images, the default configuration breaks that assumption. Deployments with reverse-proxy authentication headers enabled will accept X-WEBAUTH-USER from sources that were never supposed to be trusted. An attacker sends a request with X-WEBAUTH-USER set to an admin username, and Gitea obligingly h ands them that admin's session. No credential check, no second factor, no token. The header is the authentication.
Because the bypass lets an attacker specify any username, the ceiling is total compromise. Impersonate an administrator and you own the repositories, the webhooks, the deploy keys, the CI/CD secrets, and the ability to push malicious commits into everything downstream that trusts this Git server. Treat any exposed, unpatched instance as already breached until logs prove otherwise.
The exploitation timeline
This is a genuine active-exploitation story, not a proof-of-concept warning. The advisory for CVE-2026-20896 was published, and first in-the-wild exploitation followed 13 days later, well inside the window most organizations need just to notice a new CVE, let alone deploy a patched container across their fleet. The takeaway for defenders is blunt: the patch gap here is measured in days, and the attacker cost is a single crafted request.
Patch carefully: 1.26.3 is not enough
Gitea shipped a fix in 1.26.3, but that release introduced a regression, and 1.26.4 is the version that resolves both the vulnerability and the regression. Do not stop at 1.26.3. Pull the official image at 1.26.4 or later, redeploy, and confirm the running container reports the patched version rather than assuming your orchestration picked up the new tag.
- Upgrade the official Gitea Docker image to 1.26.4 or later; do not settle for 1.26.3, which carries a known regression.
- Set REVERSE_PROXY_TRUSTED_PROXIES to the explicit IP addresses of your real proxies. Never use a wildcard, which trusts every source.
- If you do not use reverse-proxy authentication, disable it entirely so X-WEBAUTH-USER is ignored.
- Restrict public exposure. A self-hosted Git server rarely needs to answer requests from the entire internet; put it behind VPN or IP allowlisting.
Assume compromise and hunt for it
Patching closes the door, but if your instance was exposed and unpatched during the exploitation window, you need to determine whether someone already walked through it. Review access logs for requests carrying an X-WEBAUTH-USER header from IPs that are not your legitimate proxy. Look for admin logins with no corresponding credential event, new or altered SSH and deploy keys, unexpected webhook changes, and repository pushes or org membership changes you cannot account for. Because the bypass leaves a valid-looking session, the header origin in your proxy and application logs is often the clearest tell.
X-WEBAUTH-USER, X-Forwarded-For, X-Remote-User and their cousins show up across countless self-hosted apps, and every one of them is only as safe as the network boundary that is supposed to strip client-supplied copies. Audit every service in your stack that authenticates on a trusted header, confirm the upstream proxy strips inbound copies of that header, and never leave the trusted-proxy list set to a wildcard default.
Gitea is a supply-chain chokepoint: it holds your source, your build config, and the keys to your pipeline. An auth bypass that hands an attacker administrator access to that chokepoint is about as bad as self-hosted vulnerabilities get. With active scanning confirmed and roughly 6,200 instances exposed, the safe assumption is that unpatched, internet-facing Gitea is being found right now. Get to 1.26.4, lock down the trusted-proxy list, and pull your logs before you close the ticket.
Questions about your exposure?
RedEye Security provides assessments for organizations that need to understand their real risk.
Talk to us