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 HR, payroll, or recruiting software? CleanIssue performs security audits for HR SaaS 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.
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.
Langflow CVE-2026-9198: Unauthenticated RCE on the AI Platform Under Mass Exploitation
CVE-2026-9198 (CVSS 9.8) enables full unauthenticated remote code execution on default Langflow deployments, a popular open-source AI application platform. 650 exploitation attempts recorded since July 2026.
Sources
Related services
If this topic maps to a real risk in your stack, these are the most relevant CleanIssue audits.