One HTTP header, any Gitea user: inside CVE-2026-20896

A Gitea box is not a web panel - it is your source code, the secrets developers committed by accident, and the deploy keys that reach production. CVE-2026-20896 hands all of that to an attacker with a single unauthenticated HTTP request. The official Gitea Docker image shipped REVERSE_PROXY_TRUSTED_PROXIES = **, meaning it trusted reverse-proxy authentication headers from any* source IP. On any instance where an admin had turned on reverse-proxy login, sending X-WEBAUTH-USER: admin was enough to be logged in as that user - no password, no token, no 2FA.

What actually broke

This is a packaging defect, not a code bug. Gitea gates reverse-proxy authentication on two settings. ENABLE_REVERSE_PROXY_AUTHENTICATION (default false) turns the feature on so Gitea will read a username from a trusted header. REVERSE_PROXY_TRUSTED_PROXIES decides which source IPs are allowed to assert that header - and its documented default is loopback only, 127.0.0.0/8,::1/128.

The official Docker image overrode that safe default. Its bundled app.ini template hard-coded REVERSE_PROXY_TRUSTED_PROXIES = * at docker/root/etc/templates/app.ini:55 (and the rootless template at line 52). The wildcard means "trust every source as a proxy," which disables the IP check that is supposed to ensure only your real front-end can vouch for an identity. Binary and source installs that follow app.example.ini keep the loopback default and were never affected.

The exploit: one header, web session, done

When the feature is on, Gitea reads the authenticated username from X-WEBAUTH-USER (the header name is configurable, so confirm yours). An attacker sets it to any valid or guessable login - admin and gitea_admin are the obvious picks. The public proof-of-concept confirms the bypass grants a web session only: the browser UI renders as the impersonated user, while the token API at /api/v1/... ignores the header. That is plenty - the attacker drives the UI to read private repos, add SSH or deploy keys, edit webhooks, and mint an API token, then pivots. If ENABLE_REVERSE_PROXY_AUTO_REGISTRATION is on, spoofing an unknown username even creates the account on the fly.

# Once the precondition holds, the whole exploit is one request:
curl -H "X-WEBAUTH-USER: admin" http://<target>:3000/user/settings
# No header  -> 303 redirect to /user/login  (not authenticated)
# With header -> 200, rendered as 'admin'     (authenticated, no creds)

The exploitation chain

From an exposed instance to a supply-chain pivot, the path is short. The one decision point - the three-part precondition - is where the entire chain lives or dies, and it is also the cheapest place to break it.

Am I affected?

You are exposed only if all three conditions hold. Miss any one and the wildcard is inert.

A safe self-test on a box you own: compare an anonymous request to one carrying the header. If curl -H 'X-WEBAUTH-USER: gitea_admin' https://<host>/user/settings returns 200 where the plain request redirects to /user/login, the header is being trusted and you are vulnerable.

Timeline

Is it being exploited?

Yes, but state it carefully. Sysdig reported detecting the first in-the-wild hit roughly 13 days after disclosure, traced to a ProtonVPN exit node - characterized as early-stage reconnaissance and attempted bypass, with no confirmed successful breach. That signal is currently single-source; no GreyNoise or Shadowserver tag has surfaced for this CVE. The bug is not on CISA KEV, and EPSS sits low at ~0.78% - which reflects the narrow precondition, not the ease of hitting a matching instance. Do not let a low EPSS talk you out of patching a box that meets all three conditions.

How to detect it

Gitea's access log does not record inbound request headers, so the reliable detection point is the reverse proxy, WAF, or load balancer that terminates the connection. A proxy that legitimately sets X-WEBAUTH-USER should always strip any inbound copy first - so any inbound value from a client is anomalous. Log the header, then alert on it arriving from a source outside your trusted proxy set, and hunt downstream for privileged actions with no preceding login.

# 1) log the header at the edge (nginx)
log_format webauth '$remote_addr - $host [$time_local] "$request" '
                   '$status hdr_webauth="$http_x_webauth_user"';
access_log /var/log/nginx/gitea.log webauth;

# 2) hunt: header value = a privileged login, from a non-proxy source
# grep -iE 'hdr_webauth="(admin|gitea_admin|root)"' /var/log/nginx/gitea.log

# 3) post-compromise: new SSH/deploy keys, new tokens, or new admin users
#    attributed to admin/gitea_admin with NO preceding password/2FA login

How to fix it

1. Upgrade the image to 1.26.4 (or later). The fix removes the wildcard from the Docker templates so reverse-proxy auth becomes genuinely opt-in.
2. Fix the persisted config too: upgrading the image does not rewrite an app.ini you already mounted with ''. Set REVERSE_PROXY_TRUSTED_PROXIES to your real proxy CIDR (never '').
3. If you do not use header auth, disable it: ENABLE_REVERSE_PROXY_AUTHENTICATION = false. That alone neutralizes the flaw.
4. Network-isolate the port so only the proxy can reach Gitea - do not publish it to 0.0.0.0.
5. Strip inbound X-WEBAUTH-USER (and its companions) at the proxy edge before your proxy sets its own.
6. Then hunt - a spoofed session left no failed-login trail, so a clean auth log does not clear a previously-exposed box.

Sources

• Gitea security advisory GHSA-f75j-4cw6-rmx4
• Gitea PR #38151 - the fix
• Gitea configuration cheat sheet
• Gitea blog - Release of 1.26.3 and 1.26.4
• NVD - CVE-2026-20896
• SecurityWeek - Critical Gitea flaw under active exploitation
• The Hacker News - Threat actors probe Gitea Docker flaw
• The Stack - Critical Gitea vulnerability exploited
• Rescana - Active exploitation alert (CVE-2026-20896)
• CyCognito - Gitea authentication bypasses
• Hive Security - Gitea/Forgejo 1.26.3 security release