Gitea’s Critical Docker Auth Bypass Is Now Under Active Exploitation

A critical authentication-bypass vulnerability in Gitea’s official Docker images is now being probed by real attackers, just weeks after a fix shipped.

Cloud security firm Sysdig says it detected the first in-the-wild exploitation attempt against CVE-2026-20896, a critical-severity flaw (CVSS 9.8) in the self-hosted Git service Gitea, 13 days after the vulnerability’s public disclosure. The bug lets anyone who can reach a vulnerable container’s HTTP port directly impersonate any Gitea user (including admins) by sending a single forged HTTP header, with no password or token required.

How a single header defeats Gitea’s login

The flaw lives in Gitea’s Docker packaging, not its core authentication code. Gitea supports an optional “reverse-proxy authentication” mode for setups where a trusted proxy sits in front of Gitea and vouches for a user’s identity by attaching an X-WEBAUTH-USER header. Gitea is supposed to trust that header only when it arrives from a proxy listed in REVERSE_PROXY_TRUSTED_PROXIES, which the documented safe default restricts to loopback addresses (127.0.0.0/8,::1/128).

The official Docker images shipped a different default: a wildcard, REVERSE_PROXY_TRUSTED_PROXIES = *. Per the GitHub security advisory, that wildcard means any admin who turns on ENABLE_REVERSE_PROXY_AUTHENTICATION = true to put Gitea behind a proxy ends up trusting the X-WEBAUTH-USER header from any network source that can reach the container’s port directly, not just the intended proxy. Anyone who already knows or can guess a username, including default accounts like admin or gitea_admin, can be authenticated as that user with nothing more than the header. If the admin has also enabled auto-registration, the same primitive lets an attacker create new accounts under any username they choose.

The bug was reported by researcher Ali Mustafa (GitHub handle rz1027), credited in Gitea’s advisory and named directly in a statement to The Hacker News. Binary distributions and self-built Gitea deployments that follow the documented example configuration are not affected: the flaw is specific to the official Docker images.

Sysdig catches a scanner testing the door

Gitea patched the issue in version 1.26.3, released June 20, with 1.26.4 following a day later carrying the fix forward alongside unrelated bug fixes. The advisory went public June 21. According to The Hacker News, Sysdig’s Michael Clark, senior director of threat research, said the company’s sensors caught the first real-world probe 13 days later, traced to a ProtonVPN exit node (159.26.98[.]241). “So far, the activities have been related to initial investigation by the threat actor,” Clark said, adding that the attempt “has not so far progressed to any exploitation or attack progress,” in part because Sysdig caught it early.

Sysdig’s internet-wide scanning found roughly 6,200 Gitea instances reachable from the public internet; the firm has not said how many of those are still running unpatched Docker images with reverse-proxy authentication turned on. SecurityWeek notes that a successful attack can expose everything a compromised account’s repositories hold: source code, CI/CD configuration, deploy keys, and any secrets developers have committed by accident, such as API keys or database credentials.

What Gitea admins should do now

The fix is a version upgrade, not a config tweak layered on an old release: Gitea Docker deployments should move to 1.26.3 or later, which removes the wildcard default and makes reverse-proxy authentication opt-in and admin-configured rather than silently trusted. Administrators who can’t upgrade immediately should confirm whether ENABLE_REVERSE_PROXY_AUTHENTICATION is actually in use, and if so, restrict network access to the Gitea container’s HTTP port so only the authenticating proxy can reach it: the underlying problem is that the Docker image’s trusted-proxies allowlist wasn’t actually restricting anything.

Anyone who has been running an affected configuration should treat this as a possible compromise, not just a patch reminder: the standard response is to audit authentication logs for administrative logins or account creation that can’t be tied to a known, authorized admin, since a successful exploit leaves little other trace.

Gitea’s 1.26.3 release also closed at least seven other disclosed vulnerabilities in the same batch (including SSRF protection improvements for webhooks and migrations, a branch-write-permission escalation fix, and separate access-control fixes for cross-repository LFS object reuse and repository token scope on RSS/Atom feeds), reinforcing that the update is worth applying in full rather than patching around a single header check.

Why it matters

Gitea is popular precisely because it’s easy to self-host: a small team can stand up its own Git, issue tracking, and CI/CD platform in one Docker container instead of relying on a third-party SaaS. That convenience means its default configuration choices carry outsized weight: a packaging default that quietly ignored its own documented safe value turned a routine reverse-proxy setup into a network-wide skeleton key. The 13-day gap between disclosure and the first probe is also a reminder that “patch when convenient” isn’t a real option for critical, self-hosted developer infrastructure sitting on the open internet; automated scanning finds these windows quickly, whether or not an operator has gotten to the upgrade yet.

Sources and image credit

• GitHub Security Advisory: GHSA-f75j-4cw6-rmx4 (CVE-2026-20896)
• Gitea Blog: Gitea 1.26.3 and 1.26.4 are released
• SecurityWeek: Critical Gitea Flaw Under Active Exploitation, Researchers Warn
• The Hacker News: Threat Actors Probe Gitea Docker Flaw CVE-2026-20896 13 Days After Disclosure
• Featured image: Greece padlocked fence by Jason Blackeye, CC0 1.0 Public Domain, via Wikimedia Commons.