Security researchers have confirmed active exploitation of CVE-2026-20896, a critical authentication bypass vulnerability (CVSS: 9.8) affecting Gitea official Docker images through version 1.26.2. The flaw allows an attacker to impersonate any Gitea user — including administrators — by sending a single crafted HTTP header. No credentials required. Exploitation was first detected in the wild approximately 13 days after public disclosure, and scanning activity targeting vulnerable Gitea instances has been consistently observed since.

The root cause is a dangerously insecure default configuration baked into the official Docker images: the REVERSE_PROXY_TRUSTED_PROXIES setting defaults to * (wildcard), instructing Gitea to unconditionally trust the X-WEBAUTH-USER HTTP header from any source IP. An attacker who can reach the Gitea container’s HTTP port directly — bypassing the intended authenticating proxy — can therefore inject any username and authenticate as that user. Discovery is credited to researcher Ali Mustafa, with further analysis from Michael Clark at Sysdig. Approximately 6,200 Gitea instances are currently exposed to the internet, though not all are confirmed vulnerable. Gitea has patched the issue in versions 1.26.3 and 1.26.4, making reverse-proxy authentication opt-in by default and replacing the wildcard default with a more restrictive setting.

Successful exploitation gives an attacker full access to all repositories and secrets stored in Gitea, including API keys, database credentials, deployment tokens, and source code. This makes it a particularly attractive target for supply chain attacks and initial access operations against development-heavy organizations.

Sources

Commentary

A wildcard trusted-proxy setting shipped as the default in official Docker images is a textbook supply chain misconfiguration — the kind of thing that gets flagged in security reviews and quietly ignored under release pressure. The result is a CVSS 9.8 one-header authentication bypass that’s now being actively exploited against organizations that trusted the vendor’s official image to be safe out of the box. Red teamers should add a check for this to their internal network and Docker environment assessment playbooks; the combination of a simple trigger condition and high-value payload (source code + secrets) makes it an excellent pivot point.

Defenders: if you’re running Gitea in Docker, update to 1.26.3 or 1.26.4 immediately. If you can’t patch right now, audit your app.ini for REVERSE_PROXY_TRUSTED_PROXIES and replace * with specific trusted IP addresses, or disable reverse-proxy authentication entirely if it’s not in use. Treat any Gitea deployment running 1.26.2 or earlier as potentially compromised and rotate all secrets stored in accessible repositories.

By Allan