“No password. No token. One header. Sysdig sensors caught the first in-the-wild hit 13 days after the advisory, a VPN-exit scanner that grabbed access.” — Michael Clark, leading security researcher at Sysdig
CVE-2026-20896 and the X-WEBAUTH-USER header
Security teams have confirmed active exploitation of a critical authentication-bypass flaw tracked as CVE-2026-20896 in the official Docker image for the Gitea self-hosted Git service. The vulnerability arises when reverse-proxy authentication headers such as X-WEBAUTH-USER are enabled and the deployment is left in the image’s default configuration.
As Michael Clark warned, “Gitea's official Docker image ships REVERSE_PROXY_TRUSTED_PROXIES=*. With reverse-proxy authentication enabled, Gitea then trusts the X-WEBAUTH-USER header from any source IP so an unauthenticated internet client becomes whoever it claims to be.” In short, an attacker who can send HTTP requests directly to the container can claim any login name and Gitea will accept it without a password or token.
How the default REVERSE_PROXY_TRUSTED_PROXIES setting failed
The flaw is not in the header itself but in how the official Docker image was configured by default. The image set REVERSE_PROXY_TRUSTED_PROXIES to a wildcard, effectively telling Gitea to trust identity headers from any client IP rather than only from a trusted authenticating proxy. That trust model allows unauthenticated attackers to impersonate arbitrary users, including administrators.
The project maintainer spelled out the operational consequence in clear terms: “any process that can reach the Gitea container's HTTP port directly - not through the intended authenticating proxy - can impersonate any user whose login name is known or guessable. Admin accounts (admin, gitea_admin, etc.) are the obvious targets.”
Scope and evidence: exposed instances and active hits
Public scans show roughly 6,200 Gitea instances exposed to the web, although the exact number vulnerable to CVE-2026-20896 is unclear. Michael Clark and Sysdig reported that exploitation began less than two weeks before public disclosure, and that their sensors recorded the first in-the-wild exploitation 13 days after the advisory — a “VPN-exit scanner” that obtained access by claiming an identity via the header.
The combination of a default wildcard trust setting and open HTTP access increases the practical attack surface: any internet client that can reach the container’s HTTP port may be able to impersonate users whose login names are known or guessable.
Gitea’s remediation: 1.26.3 and 1.26.4, and operational advice
Gitea released versions 1.26.3 and 1.26.4 to address CVE-2026-20896. The project advised users to upgrade straight to the most recent release, noting that 1.26.4 also fixes an additional issue and a regression introduced in 1.26.3.
For deployments that cannot upgrade immediately, Singapore’s Cyber Security Agency (CSA) recommended a configuration change: restrict REVERSE_PROXY_TRUSTED_PROXIES to specific, trusted IP addresses instead of using the default wildcard. CSA also urged operators to review access logs for suspicious activity to determine whether a compromise has already occurred.
What this means for Singapore’s CSA, Gitea operators, and security teams
- Singapore’s CSA: has issued a public warning about CVE-2026-20896 and provided mitigation guidance — notably the restriction of trusted proxy IPs and log review — to limit ongoing exploitation.
- Gitea operators and administrators: must upgrade to the latest Gitea release (1.26.4) where possible, or immediately restrict REVERSE_PROXY_TRUSTED_PROXIES and audit access logs for signs of impersonation, especially for accounts with administrative names such as admin or gitea_admin.
- Security teams: should treat exposed Gitea HTTP endpoints as high-risk until confirmed patched or reconfigured, because the default Docker image allows unauthenticated identity assertion using a single header and no credentials.
The technical simplicity of the exploit—one header, no password or token—combined with default configuration that trusts all sources, made this vulnerability both urgent and straightforward for attackers to leverage. The measures are equally straightforward: upgrade to the patched releases, tighten proxy trust settings, and search access logs for signs of unauthorized impersonation. How many of the roughly 6,200 publicly exposed instances were abused before fixes were applied remains an open and consequential question.
Source: BleepingComputer — Hackers exploit critical auth bypass in Gitea Docker image
