CVE-2026-20896: Gitea Docker's Default REVERSE_PROXY_TRUSTED_PROXIES Wildcard Enables Full Auth Bypass via X-WEBAUTH-USER

What's happening

The official Gitea Docker image ships with REVERSE_PROXY_TRUSTED_PROXIES defaulted to *. Gitea's reverse-proxy authentication feature is designed to trust a caller-supplied X-WEBAUTH-USER header as an already-authenticated identity, but only when that header arrives from a trusted proxy. With the wildcard default, Gitea trusts every source. Any unauthenticated attacker with direct network access to the Gitea HTTP listener — bypassing whatever reverse proxy the deployment intended to sit in front of it — can set X-WEBAUTH-USER: admin (or any other username) and be handed a fully authenticated session, no credentials required. This is a classic improper-access-control flaw (CWE-284): the trust decision for a privileged header is effectively disabled by the shipped default configuration.

Affected software

• Vendor: go / Gitea project
• Product: code.gitea.io/gitea
• Affected versions: < 1.26.3

Exploitation status

A public proof-of-concept exists (poc-public). No CVSS-driving weaponized campaign is confirmed at time of writing, but with a CVSS score of 9.8 and a trivially reproducible bypass (a single crafted header), defenders should treat this as high-priority: any Gitea instance where the HTTP port is reachable without an enforcing proxy in front of it is exposed to unauthenticated admin takeover the moment a PoC is adapted into a scanner or worm.

How our detection catches it

Our coverage spans Microsoft Sentinel (KQL), Splunk (SPL), Elastic (EQL), QRadar (AQL), Sumo Logic, Chronicle (YARA-L), and CrowdStrike (CQL). The core detection logic flags two conditions:

• HTTP requests to Gitea carrying X-WEBAUTH-USER (or equivalent reverse-proxy auth headers) where the source IP falls outside the expected reverse-proxy/load-balancer CIDR range.
• Successful authentications attributed to reverse-proxy auth that have no corresponding log entry from the upstream proxy tier — indicating the header was injected directly rather than passed through a legitimate, trusted hop.

This lets defenders catch the bypass regardless of which SIEM they run, without needing to inspect application source or rely solely on patch status.

Remediation and full detection details

Upgrade to Gitea 1.26.3 or later, and explicitly scope REVERSE_PROXY_TRUSTED_PROXIES to your actual proxy CIDR rather than relying on the default. For the full detection queries across all supported SIEM platforms, see the CVE-2026-20896 detection page.