Gitea Auth Bypass: One Header, Full Admin

On January 14, 2025, security researcher Michael Clark confirmed what Sysdig had already detected: attackers were exploiting CVE-2026-20896 to bypass authentication in Gitea Docker deployments. This vulnerability allowed anyone to impersonate any user, including administrators, by sending a single HTTP header. No credentials were required.

What Happened

Gitea, a self-hosted Git service used by development teams, shipped with a Docker configuration that trusted reverse proxy headers by default. The REVERSE_PROXY_TRUSTED_PROXIES setting was set to *, meaning Gitea would accept authentication headers from any source without verification.

An attacker could send an HTTP request with X-Forwarded-User: admin, and Gitea would grant admin access. No password, token, or authentication challenge was needed.

The vulnerability affected all Gitea Docker images through version 1.26.2. With 6,200 Gitea instances exposed on the public web, the attack surface was significant.

Timeline

• January 2025: Sysdig detects active exploitation
• Less than two weeks later: Public disclosure of CVE-2026-20896
• January 14, 2025: Michael Clark confirms exploitation and details the attack vector
• Version 1.26.3: Patch released, changing default to empty string (no trusted proxies)

The gap between exploitation and disclosure was narrow. Attackers moved fast.

Which Controls Failed

1. Secure defaults were missing

The Docker image shipped with REVERSE_PROXY_TRUSTED_PROXIES=*, assuming every request came from a trusted proxy. Many deployments expose Gitea directly to the internet or sit behind proxies that don't strip authentication headers.

2. Configuration validation didn't exist

Gitea didn't warn administrators that their deployment was accepting authentication headers from untrusted sources. The setting was buried in configuration files, not highlighted during setup.

3. Defense in depth was absent

Even with a misconfigured reverse proxy setting, authentication should require verification. Gitea's design allowed a single header to bypass the entire authentication layer.

4. Attack surface wasn't minimized

The Docker image included this risky feature enabled by default. Most users don't need reverse proxy authentication, but they got the risk anyway.

What the Standards Require

OWASP ASVS v4.0.3, Requirement 2.2.1: "Verify that anti-automation controls are effective at mitigating breached credential testing, brute force, and account lockout attacks."

Accepting unauthenticated headers violates this at the most basic level. There's no credential testing to breach when you can skip credentials entirely.

NIST 800-53 Rev 5, Control IA-2: "Uniquely identify and authenticate organizational users."

The control requires authentication before granting access. Trusting an HTTP header from an unverified source doesn't meet this requirement. The system must verify the user's identity, not accept a claim from any client.

PCI DSS v4.0.1, Requirement 6.2.4: "Software and firmware are kept up to date and free from known vulnerabilities."

This applies to both Gitea itself and the deployment configuration. Running default settings that create authentication bypass vulnerabilities violates this requirement, even if the software is technically "patched."

ISO 27001, Control 5.15: "Access control rules are established, documented, and reviewed."

Default configurations that grant access based on unverified headers fail this control. Access control rules must be explicit, not implicit trust relationships baked into defaults.

Lessons and Action Items

For your Gitea deployment:

1. Update to version 1.26.3 or later immediately.
2. Set REVERSE_PROXY_TRUSTED_PROXIES to an empty string unless you have a specific, documented need for reverse proxy authentication.
3. If you use reverse proxy auth, list specific IP addresses or CIDR ranges; never use *.
4. Verify your reverse proxy strips authentication headers from client requests before forwarding to Gitea.

For any reverse proxy deployment:

1. Document which headers your proxy forwards and why.
2. Configure your proxy to strip X-Forwarded-User, X-Forwarded-Email, and similar authentication headers from untrusted sources.
3. Test your configuration by sending crafted headers from outside your network.
4. Review logs for requests containing authentication headers that didn't originate from your proxy.

For your software supply chain:

1. Audit default configurations in your Docker images and deployment templates.
2. Flag any setting that assumes trust without verification.
3. Build a review process for configuration changes in base images.
4. Test your deployments with hostile input, not just valid use cases.

For your vulnerability response process:

1. Subscribe to security advisories for every open-source component in your stack.
2. Measure time-to-patch for critical vulnerabilities (this one was exploited within two weeks).
3. Maintain an inventory of public-facing instances so you can identify exposure quickly.
4. Run authenticated and unauthenticated scans against your own deployments to catch misconfigurations.

The Gitea vulnerability wasn't a zero-day exploit requiring sophisticated techniques. It was a default configuration that trusted the wrong thing. Your environment likely has similar assumptions buried in configuration files. Find them before attackers do.