Active attacks exploit critical Gitea Docker auth bug

A critical flaw in Gitea’s official Docker images (CVE-2026-20896, CVSS 9.8) allows an attacker to bypass authentication by sending a single HTTP header containing a valid username. Security firm Sysdig recorded exploitation in the wild 13 days after the vulnerability was publicly disclosed.

The vulnerability stems from how reverse-proxy authentication was configured in Gitea Docker images released before versions 1.26.3 and 1.26.4. Default settings accepted connections from any source IP instead of enforcing an allowlist, and Gitea trusted an authentication header that should only be set by a fronting proxy. Any process that can reach a container’s HTTP port directly can supply a username in that header and be treated as that user without a password or token.

Security researcher Ali Mustafa, who discovered the flaw, warned that ‘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 are the obvious targets.’

Michael Clark, Sysdig’s senior director of threat research, reported that the first in-the-wild attempt was tied to a VPN-exit scanner probing exposed instances. Clark summarized the exploitation simply: ‘No password. No token. One header.’ Sysdig’s scans identified roughly 6,200 Gitea instances reachable from the public internet; it is not yet clear how many of those run vulnerable images or configurations.

Successful exploitation can let an attacker read and write repositories, including private code, and retrieve secrets that developers may have committed by mistake, such as API keys, database credentials, deploy tokens, CI/CD configuration and deploy keys. That level of access can enable complete compromise of projects and development infrastructure hosted in the affected instance.

Gitea released fixes in versions 1.26.3 and 1.26.4 that make reverse-proxy authentication opt-in and correct the allowlist behavior. Administrators are advised to update affected deployments immediately. Operators should also ensure only trusted proxies can reach Gitea’s HTTP port, accept authentication headers only from those proxies and restrict network access so containers are not directly reachable from untrusted networks.

Gitea is a lightweight, self-hosted Git service used to host source code and automation pipelines. Because repositories often include deploy keys and CI credentials, a compromise of a code-hosting instance can expose both source code and operational secrets.