One Header to Rule Them All: Critical Gitea Bug Lets Attackers Walk Right In
It took just 13 days after the advisory went public for attackers to start exploiting a critical vulnerability in Gitea, the popular self-hosted Git service. The bug, tracked as CVE-2026-20896, carries a CVSS score of 9.8. And the attack vector is almost absurdly simple: a single HTTP header containing a valid username.
No password. No token. Just a header. Sysdig’s senior director of threat research, Michael Clark, confirmed that the company’s sensors caught the first in-the-wild hit less than two weeks after the flaw was disclosed. The attempt was linked to what Clark described as a “VPN-exit scanner that grabbed access.”
This isn’t a theoretical risk. It’s happening now.
What Makes CVE-2026-20896 So Dangerous?
The vulnerability lives in Gitea’s reverse-proxy authentication mechanism — specifically in the official Docker images. Security researcher Ali Mustafa, who discovered the bug, explains that in Gitea Docker images before version 1.26.3, the default configuration allows connections from any source IP address. It doesn’t enforce an allowlist.
Here’s the problem: when reverse-proxy authentication is enabled, Gitea should only trust a header that was set by the proxy itself. But because of this flaw, anyone who can reach the Gitea container’s HTTP port directly — sidestepping the authenticating proxy — can impersonate any user whose login name they know or can guess.
And guess what? Admin accounts are the obvious target. “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,” Mustafa noted.
The fix, rolled out in Gitea versions 1.26.3 and 1.26.4, makes reverse-proxy authentication an opt-in feature. That’s a smart move — it means the dangerous default is no longer the default.
What Attackers Can Do Once They’re In
The consequences of a successful exploit are severe. Clark laid it out bluntly: a Gitea user can read and write their own repositories, including private ones. That means attackers can access:
- The code your organization ships to production
- Secrets developers accidentally committed — API keys, database credentials, deploy tokens
- CI/CD configuration files
- Deploy keys that can unlock other systems
In other words, a single header can lead to the complete compromise of everything Gitea holds. Code, secrets, infrastructure access — all up for grabs.
How Many Instances Are Exposed?
Sysdig’s research found roughly 6,200 Gitea instances accessible from the internet. How many of those are running vulnerable versions is unclear. But given that the flaw was only recently patched, and that many organizations are slow to update, the number could be significant.
If you’re running Gitea in a Docker container, now is the time to check your version. The attack surface is real, and the window for patching is closing fast.
What You Should Do Right Now
The advice from researchers is straightforward: update your Gitea deployments immediately. If you’re on a version before 1.26.3, you’re exposed. The patch changes the default behavior so that reverse-proxy authentication must be explicitly enabled, rather than being on by default.
Beyond updating, consider whether you even need reverse-proxy authentication. If you do, make sure your proxy is properly configured to set the trusted header, and that no other process can reach the Gitea container’s HTTP port directly. Network segmentation is your friend here.
This isn’t the first time Gitea has been in the spotlight for security issues. A previous vulnerability exposed roughly 30,000 deployments to attacks. And with critical Adobe ColdFusion vulnerabilities and actively exploited Microsoft SharePoint flaws also making headlines, it’s clear that the threat landscape is crowded. Don’t let your Gitea instance become the weak link.
Patch now. Because one header is all it takes.
