Security researcher Ali Mustafa disclosed CVE-2026-20896 (CVSS 9.8), a critical authentication bypass in Gitea’s official Docker images that lets an unauthenticated network client assume the identity of any user — including an instance administrator — by sending a single spoofed HTTP header. Cloud security firm Sysdig detected the first in-the-wild probing of the flaw 13 days after public disclosure, and roughly 6,200 internet-facing Gitea instances are reachable today.

What happened

Gitea supports “reverse proxy authentication,” a legitimate feature where a front-end proxy (nginx, Apache, an SSO gateway) authenticates the user and passes their identity to Gitea via the X-WEBAUTH-USER header. Gitea trusts that header completely and logs the named user in — no password, no session cookie, no token. The security of the whole scheme depends entirely on Gitea only accepting that header from the trusted proxy’s IP, never from the public internet.

The official Gitea Docker images broke that assumption. The bundled app.ini template hard-codes:

1
2

[security]
REVERSE_PROXY_TRUSTED_PROXIES = *

The wildcard means Gitea will honor an X-WEBAUTH-USER header from any source address, not just a configured reverse proxy. Any client that can reach the Gitea port directly — internet-facing deployments, internal attackers, lateral movement from an adjacent container — can set the header to admin (or any known username) and be authenticated as that user with zero credentials. It’s a single curl request: add one header, get a session as an administrator.

Affected versions and fix

The flaw affects Gitea Docker images through version 1.26.2. It’s fixed in 1.26.3, released in June 2026, which removes the wildcard default and makes reverse-proxy trust opt-in — operators must now explicitly list the trusted proxy IPs/CIDRs. Non-Docker installs that manually configured REVERSE_PROXY_TRUSTED_PROXIES were never affected by the default, but any deployment (Docker or not) that set the value to * for convenience carries the same exposure.

Impact

An attacker who authenticates as an admin gets full control of the Gitea instance: read/write access to every repository (public and private), the ability to push malicious commits or tags, management of webhooks and Actions runners (a direct path to CI/CD compromise and secret exfiltration), user and SSH-key administration, and instance-wide configuration changes. Because Gitea is frequently used as an internal, self-hosted alternative to GitHub specifically to keep source and secrets off third-party infrastructure, a compromised instance is often a bigger blast radius than a single SaaS account — it’s the org’s whole internal source-control and build-trigger surface.

Sysdig’s telemetry shows the exploitation curve is still early: the first observed probe came from a ProtonVPN exit node and consisted of reconnaissance rather than a completed takeover, but the technique requires no tooling beyond a single crafted request, so the barrier to a real attack is close to zero once an instance is found.

Mitigation

  1. Upgrade to Gitea 1.26.3 or later immediately if running the Docker image. This removes the wildcard trust default.
  2. Audit app.ini on every instance, containerized or not, for REVERSE_PROXY_TRUSTED_PROXIES. If it’s set to * or left at a permissive range, restrict it to the exact IP(s) of your actual reverse proxy.
  3. Don’t expose the Gitea port directly to the internet — put it behind a proxy that strips inbound X-WEBAUTH-USER headers from client requests and only forwards a value it sets itself.
  4. Check access and audit logs for authentication events tied to X-WEBAUTH-USER from unexpected source IPs, especially VPN/hosting-provider ranges.
  5. Rotate credentials and review admin/user lists on any instance that was internet-reachable on a vulnerable version, since a successful spoof leaves no password change and can be hard to distinguish from legitimate SSO logins after the fact.

References