A critical flaw in Gitea’s official Docker images, CVE-2026-20896, let an unauthenticated internet client impersonate any user, including administrators, by simply setting a header. Rated CVSS 9.8, it was patched in version 1.26.3, and security firm Sysdig detected the first in-the-wild exploitation attempt 13 days after public disclosure.

  • The bug: Gitea’s Docker image trusted the X-WEBAUTH-USER header from any source IP, so anyone could claim to be any user.
  • It affects Gitea Docker images up to and including 1.26.2; the fix in 1.26.3 removes the wildcard and makes reverse-proxy auth opt-in.
  • Severity is CVSS 9.8: unauthenticated, network-reachable, full account takeover including admin.
  • Sysdig observed the first exploit attempt 13 days after disclosure, a reminder that patch windows are short.
How the X-WEBAUTH-USER trust bug works Reverse-proxy auth is meant to trust the header only from the proxy; the vulnerable Docker image trusted it from any IP, letting an attacker set X-WEBAUTH-USER to admin. Intended Trusted proxy Gitea header ok Exploited Any attacker Gitea (1.26.2) X-WEBAUTH-USER: admin → logged in as admin trusted fromany IP genztech.blog
Fig 1 Reverse-proxy header auth is safe only when the header is trusted from the proxy alone. The vulnerable image trusted it from anywhere, turning one header into full account takeover.

What is the actual vulnerability?

Gitea supports reverse-proxy authentication: a trusted proxy in front of Gitea authenticates the user and passes the identity along in the X-WEBAUTH-USER HTTP header. That pattern is fine as long as Gitea only trusts the header when it comes from the proxy. The vulnerable Docker images shipped with a configuration that trusted X-WEBAUTH-USER from any source IP address. The result: any client that could reach the instance over the network could send a request with that header set to any username and be authenticated as that user, no password required. Set it to an administrator account and you own the instance. The CVSS 9.8 score reflects exactly that: unauthenticated, remotely exploitable, complete compromise.

RelatedGhostLock: a 15-year Linux bug hands attackers root

Why did the Docker image ship this way?

Because a convenience default became a security hole at scale. Trusting the proxy header out of the box makes the reverse-proxy setup work with less configuration, which is friendly for the common deployment. But a container image is used by thousands of operators who never change defaults, many of whom expose the service more broadly than the design assumed. A default that is safe behind a locked-down proxy is catastrophic the moment the instance is reachable from the internet. The 1.26.3 fix removes the wildcard trust and makes reverse-proxy auth something you opt into deliberately, which is the correct posture: secure by default, convenient by choice.

How urgent is patching?

Very. Sysdig reported detecting the first in-the-wild exploitation attempt 13 days after the flaw was disclosed. That is the pattern defenders should internalize: public disclosure starts a clock, and for a trivially exploitable, maximum-severity bug in a widely deployed self-hosted tool, the window between disclosure and mass scanning is measured in days, not months. Self-hosted developer infrastructure like Gitea is a high-value target because it holds source code, secrets and CI credentials.

What to do now
  • Upgrade to 1.26.3 or later immediately. This is the only complete fix; there is no safe workaround that keeps the wildcard trust.
  • Audit for compromise. Check for unexpected admin logins or new tokens created since your image was last updated.
  • Lock down exposure. Self-hosted Git should not be openly internet-reachable without a hardened proxy and network controls.

What should teams learn from this pattern?

The broader lesson reaches well beyond Gitea. Container images encode defaults that most operators never touch, which means a single insecure default becomes an internet-scale exposure the moment the image is popular. The reverse-proxy header pattern is used across a lot of self-hosted software, and the failure mode here, trusting an identity header from any source instead of only from the proxy, is a mistake other projects have made and will make again. If you run self-hosted infrastructure, the defensive posture is to assume that any header your application trusts for authentication can be forged unless the network path guarantees it came from where you think. That means terminating trust at a proxy you control, stripping client-supplied auth headers at the edge, and never exposing an internal management interface directly to the internet. It also means treating your own dependency images as a supply-chain surface: pin versions, watch for security releases, and have a same-week patching process for anything rated critical. The teams that got burned by this were not careless so much as trusting a default that looked reasonable. The ones that stayed safe had defense in depth that did not rely on the application's config being perfect.

RelatedWinRAR Heap Overflow CVE-2026-14191 Needs a Manual Patch

Our take

This is a textbook example of how default configurations in container images become internet-scale vulnerabilities. The underlying feature is not wrong; trusting a proxy header is a normal pattern. Shipping it trusted from everywhere is the mistake, and it is one that only shows up when tens of thousands of operators run the image unchanged. The 13-day exploit timeline is the part worth remembering: if you run self-hosted developer tools, patching critical CVEs is not a monthly chore, it is a same-week emergency. Update to 1.26.3 today if you have not.

Primary sources

Original analysis by GenZTech. Figures current as of July 2026. Source: The Hacker News.