Hackers Exploit Gitea Docker Flaw Just 13 Days After the Patch

Hackers are actively probing Gitea’s official Docker image for a bug that lets anyone impersonate an administrator with one forged HTTP header. Gitea is a self-hosted Git platform many DevOps teams run instead of GitHub. The flaw, tracked as CVE-2026-20896, carries a CVSS score of 9.8, and cloud security firm Sysdig says exploitation began just 13 days after Gitea’s fix shipped.

Roughly 6,200 Gitea instances sit exposed on the open internet, and nobody outside the attackers knows how many are still running the broken default. It is also the second time in three months that a Gitea packaging default, not a code bug, has put tens of thousands of repositories within a stranger’s reach.

The Header That Fooled Gitea’s Login

Gitea is a lightweight, self-hosted Git service. Teams install it on their own servers to store code, review pull requests, and run the CI/CD pipelines that build and ship software automatically.

Many of those teams put a reverse proxy, something like Nginx or Traefik, in front of Gitea to handle logins, then let that proxy vouch for a user by attaching a header called X-WEBAUTH-USER to every request. That setup only works if Gitea trusts the header from the proxy alone, and nowhere else.

The official Docker image did not enforce that. It shipped an app.ini configuration template that hard coded REVERSE_PROXY_TRUSTED_PROXIES = *, instead of the documented safe value of 127.0.0.0/8,::1/128, which limits trust to the local machine. Once an administrator switched on reverse proxy authentication, that wildcard meant Gitea would trust the header from any source on the internet.

Security researcher Ali Mustafa, who publishes as @rz1027 and is credited with reporting the flaw, told The Hacker News that “with reverse proxy login enabled, that wildcard trusts every source IP, so anyone who could reach the port could send an X-WEBAUTH-USER header,” and would be logged in as whichever account name the header claimed. Gitea’s own advisory is blunt about the blast radius: “Any process that can reach the Gitea container’s HTTP port directly” can pose as any user whose login name is known or guessable, rather than going through the intended authenticating proxy, with accounts like admin and gitea_admin named as the obvious targets.

Thirteen Days from Patch to Probe

Gitea’s own changelog shows the fix landed in version 1.26.3 on June 18, 2026, bundled with a batch of other security fixes. A regression in that release broke code browsing on some repositories, so Gitea pushed 1.26.4 three days later, on June 21, closing the gap and, per the official 1.26.4 release announcement, fixing one more issue: disabled accounts that could silently reactivate through an OAuth2 login callback.

TechTimes reported that automated scanners had been trying to walk into Gitea repositories since July 7, exactly 13 days after Gitea’s advisory went out, tracing the first probe to a scanner running through a ProtonVPN exit node.

Sysdig is the same firm that recently disclosed the first known agentic ransomware attack on a live production network. Michael Clark, senior director of threat research at Sysdig, said the scanning IP, 159.26.98[.]241, had not progressed past initial reconnaissance when his team caught it. “While we saw the first action from an IP from the ProtonVPN service,” Clark told The Hacker News, “it has not so far progressed to any exploitation or attack progress. We think this is because we have seen this one early before it has had the chance to develop beyond that initial phase.”

1. May 20, 2026: Gitea patches a separate flaw in its container registry, CVE-2026-27771, in version 1.26.2.
2. June 18, 2026: Version 1.26.3 fixes the Docker authentication bypass along with nine other issues, according to Gitea’s own release notes.
3. June 21, 2026: Version 1.26.4 follows to patch a regression in 1.26.3 plus one additional security issue.
4. July 7, 2026: Sysdig’s sensors catch the first in-the-wild exploitation attempt, a scanner operating through a ProtonVPN exit node.

Clark’s team has not seen the activity progress beyond that initial reconnaissance. What a successful attempt would expose is the harder question.

Why This Bug Reaches Beyond One Company

A compromised Gitea instance is not a leaked login panel. Teams store private repositories on it, manage pull requests through it, and run the CI/CD pipelines that build and ship finished software from it.

User access on a Gitea box isn’t ‘a web panel,’ it’s your source code. A Gitea user can read and write their repositories, private ones included: the code they ship, the secrets developers committed by accident (API keys, DB credentials, deploy tokens), their CI/CD config, and deploy keys.

Michael Clark wrote that assessment in a LinkedIn post that Security Affairs and other outlets picked up after the exploitation began.

Researchers keep reaching for the same comparison: an attacker who controls a CI/CD pipeline can slip malicious code into a build before it is signed and shipped, the same category of attack behind the 2020 SolarWinds breach and the Red Hat npm ecosystem incident in June 2026. A compromised Gitea box does not stop at the company running it. It can reach every customer who later installs software built from that box.

Gitea’s Second Docker Default Failure of 2026

This is not the first time in 2026 that a default setting inside Gitea’s own container images, rather than a bug in the platform’s code, put a large number of deployments at risk.

In May, researchers at UK security firm Noscope disclosed CVE-2026-27771, a flaw in Gitea’s built-in container registry that let anyone on the internet pull private container images without an account, a password, or any credentials at all. A separate analysis from cloud security firm Orca Security counted roughly 31,750 internet-facing instances likely affected, spread across more than 30 countries with the heaviest concentrations in China, the United States, and Germany. The flaw had gone unnoticed for close to four years since the registry feature shipped.

Both flaws share a root cause. A setting the Gitea project documents as safe got silently overridden somewhere between the source code and the shipped artifact. Researchers at Hive Security, who reviewed the full patch batch for TechTimes, found a pattern rather than a single mistake: wildcard proxy trust, TOTP codes that were checked but never consumed, and permission checks that drifted apart across the API and the web interface. Individually, none of those looked careless. Together, they point to a security model that was never re-verified as a whole while new features kept landing on top of it.

Is Your Gitea Instance Exposed?

Your instance is at risk only if it runs the official Docker image at version 1.26.2 or earlier, has ENABLE_REVERSE_PROXY_AUTHENTICATION set to true, and its HTTP port can be reached by anything other than your own reverse proxy. Binary installs and self-built deployments that follow Gitea’s documented defaults keep the safe loopback-only setting and are not affected.

Checking is straightforward. Look at the app.ini file or Docker environment variables for that authentication setting. If it is enabled, check whether REVERSE_PROXY_TRUSTED_PROXIES was ever changed from the wildcard. If it was not, the instance is exposed to anyone who can reach its HTTP port, including through network routing that accidentally bypasses the intended proxy.

• Upgrade first – move every Docker deployment straight to version 1.26.4 or later, prioritizing internet-facing and business-critical instances. Gitea’s own guidance is to back up data before replacing the running container, since 1.26.3 alone still carries the code-page regression.
• Cut off direct access – firewall the container’s HTTP port so only the intended reverse proxy can reach it, not the wider internet or an untrusted internal segment.
• Lock down the trust setting – replace the wildcard with the specific IP address of the real proxy, or the documented loopback-only value, and audit logs for X-WEBAUTH-USER headers arriving from anywhere else.

Singapore’s Cyber Security Agency (CSA) issued its own warning that CVE-2026-20896 is under active exploitation and pointed operators toward the same trusted-proxy fix if an immediate upgrade is not possible.

Nine Other Bugs Rode the Same Patch

The header bypass earned the CVSS 9.8 score and the headlines, but Gitea’s release notes bundle nine other fixes into the same 1.26.3 and 1.26.4 releases. Among the named ones: an SSRF bypass in webhook and migration allowlists, tracked as CVE-2026-22874, that could reach internal services from Gitea’s own server context; a per-branch write permission escalation, CVE-2026-27775, that let a maintainer-level token climb to full repository write access; and an organization label leak tracked as CVE-2026-25038.

None of those nine carry the same blast radius as the header bypass on their own. Bundled into one upgrade, they are a reminder that an admin who checks a version number and stops there is still leaving several doors unlocked.

Gitea’s release notes for 1.26.3 warn that the version broke some repository code pages and urge upgrading straight to 1.26.4, which also stops disabled accounts from silently reactivating through an OAuth2 login callback.

Forgejo, the community-run fork of Gitea, shares much of that same authentication code and shipped coordinated patches for the identical header bypass the same week Gitea did. Anyone running Forgejo instead of Gitea needs the same version check.

Frequently Asked Questions

What is CVE-2026-20896?

CVE-2026-20896 is a critical authentication bypass, rated 9.8 out of 10 on the CVSS scale, found in official Gitea Docker images through version 1.26.2. It stems from a default configuration that trusted an identity header from any source instead of only from an approved reverse proxy, letting an attacker impersonate any account, including an administrator, without a password.

Does This Affect Gitea Installs That Don’t Use Docker?

No. Binary installs and self-built deployments that follow Gitea’s own documentation keep the safe, loopback-only default for REVERSE_PROXY_TRUSTED_PROXIES. Only the official Docker image shipped the wildcard override, and only instances with reverse-proxy authentication switched on are exposed.

How Do I Check If My Instance Was Probed?

Search access logs for any request carrying an X-WEBAUTH-USER header that did not originate from your actual reverse proxy’s IP address. Researchers have also circulated a simple test: sending a request with that header set to admin against a vulnerable instance returns an authenticated session with no credentials supplied at all.

Is Forgejo Vulnerable Too?

Yes. Forgejo shares the same reverse-proxy authentication code as Gitea and received a coordinated patch alongside Gitea’s 1.26.3 release, so Forgejo operators need to upgrade on the same timeline rather than assuming the fork was untouched.

What If I Can’t Upgrade Right Away?

Singapore’s Cyber Security Agency recommends setting REVERSE_PROXY_TRUSTED_PROXIES to the specific IP address of your real reverse proxy instead of the wildcard, or to the documented loopback-only value of 127.0.0.0/8,::1/128, while reviewing access logs for suspicious admin activity until the upgrade is scheduled.

Were Other Vulnerabilities Fixed in the Same Update?

Yes. Gitea’s 1.26.3 and 1.26.4 releases bundled nine other fixes, including an SSRF bypass in webhook allowlists, a branch-permission escalation bug, and a fix stopping disabled accounts from silently reactivating through an OAuth2 callback.