Gitea CVE-2026-20896: a one-header auth bypass shipped in the official Docker image
> In short: CVE-2026-20896 is a critical authentication bypass (CVSS 9.8) in the official Gitea Docker image. The image shipped REVERSE_PROXY_TRUSTED_PROXIES=*, so when reverse-proxy authentication was enabled, Gitea trusted the X-WEBAUTH-USER header from any source IP. An unauthenticated internet client became any user — including admin. Actively exploited. Fix: Gitea 1.26.3 and 1.26.4.
Why this matters to you
Gitea is the self-hosted GitHub/GitLab alternative a lot of SaaS teams run for source code, pull requests, and CI/CD. Around 6,200 instances are exposed on the public internet. If your team self-hosts Gitea in Docker — for sovereignty, cost, or to keep code out of US-hosted SaaS — this CVE is a direct, unauthenticated, admin-level takeover of your source code.
And the root cause is something every team that runs containers should internalize: a default configuration that was convenient in development and catastrophic in production.
The flaw in two sentences
Reverse-proxy authentication is a legitimate Gitea feature: put Gitea behind a proxy that authenticates users and forwards their identity in the X-WEBAUTH-USER header, and Gitea trusts it. The mechanism is safe *if and only if* Gitea only accepts that header from the trusted proxy's IP.
The official Docker image shipped with REVERSE_PROXY_TRUSTED_PROXIES=*. That wildcard means: trust the identity header from any source. So any client that can reach the container's HTTP port directly — bypassing the authenticating proxy — can set X-WEBAUTH-USER: admin and become admin. No password, no token, one header. Sysdig caught the first in-the-wild scan 13 days after the advisory, a VPN-exit scanner grabbing access.
The pattern: trust without scoping
This bug is the infrastructure equivalent of the JWT flaw we see in app code: an identity claim is trusted without checking who sent it. The same anti-pattern shows up in:
X-Forwarded-For for the "real" client IP without validating the proxy chain.X-User-Id, X-Email) from a gateway, but are reachable from outside the gateway.In every case the fix is identical: explicitly enumerate the trusted sources, never use a wildcard for trust.
What to do
REVERSE_PROXY_TRUSTED_PROXIES to the explicit IP(s)/CIDR(s) of your reverse proxy — not *. If you don't actually use reverse-proxy auth, disable it entirely.X-WEBAUTH-USER activity, privilege changes, new admin accounts, or unknown SSH keys added since the advisory. The CSA Singapore has issued an alert — treat compromise as plausible until logs say otherwise.The supply-chain angle
For a SaaS vendor, a self-hosted Git server compromise is one of the worst-case scenarios: it hands the attacker your source code and your CI/CD pipeline in one move. That's the SolarWinds pattern at team scale. If you self-host Gitea (or GitLab, or Forgejo), this CVE is the prompt to treat it as production-grade infrastructure: pinned versions, reviewed defaults, network isolation, and the same patching SLA you'd apply to your application servers.
Building software? CleanIssue performs security audits for your product in real-world conditions, no source code access needed. For a first read of your exposure, start with an external review of your application.
Related articles
Three adjacent analyses to keep exploring the same attack surface.
JFrog Artifactory CVE-2026-82329: a JWT signed with an empty key grants admin rights
CVE-2026-82329 (CVSS 9.8) lets an unauthenticated attacker forge an admin JWT on unhardened self-hosted Artifactory instances by exploiting a default empty cluster join key. The resulting access controls repositories, users, and configuration — a direct software supply-chain poisoning risk.
GitLab RCE via Oj: a memory-corruption chain hidden in a non-security patch
Two Oj Ruby JSON parser bugs let any authenticated user run commands as `git` on self-managed GitLab <18.10.8 / <18.11.5 / <19.0.2, via crafted Jupyter notebooks. The fix shipped June 10 but was listed under bug fixes, not security. PoC published July 24.
JetBrains TeamCity: a critical auth bypass leading to RCE on your CI/CD server
A critical authentication bypass vulnerability in JetBrains TeamCity On-Premises could be exploited for remote code execution on the CI/CD server — giving attackers access to build pipelines, deployment credentials, and source code. Fix available.
Sources
Related services
If this topic maps to a real risk in your stack, these are the most relevant CleanIssue audits.