Back to blog
CVEGiteaDockersupply chain

Gitea CVE-2026-20896: a one-header auth bypass shipped in the official Docker image

Published on 2026-07-106 min readCleanIssue

> 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:

  • Apps behind Cloudflare/Nginx that read X-Forwarded-For for the "real" client IP without validating the proxy chain.
  • Internal services that trust headers (X-User-Id, X-Email) from a gateway, but are reachable from outside the gateway.
  • Kubernetes services that assume network policy isolates them, then expose the pod port directly via a misconfigured ingress.
  • In every case the fix is identical: explicitly enumerate the trusted sources, never use a wildcard for trust.

    What to do

  • Upgrade straight to Gitea 1.26.4 (1.26.3 fixed CVE-2026-20896 but introduced a regression). Do not stop at 1.26.3.
  • If you cannot upgrade immediately, set 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.
  • Block direct access to the Gitea container's HTTP port from outside the reverse proxy. Network-level enforcement is the backstop for a config-level bug.
  • Review access logs for suspicious 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.
  • Rotate credentials that lived in the Gitea instance: CI/CD tokens, deploy keys, anything stored in repos or as secrets. A Gitea admin can read every repo and every secret in it.
  • 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.

    Need an external review of your HR SaaS?

    Share your product, stack, and client context. We will come back with the right review scope.

    Discuss your audit