A researcher credited as rz1027 reported a critical authentication bypass in Gitea’s official Docker images to the project on 26 May 2026. Gitea shipped a fix in version 1.26.3 on 20 June, with a follow-up release, 1.26.4, a day later. Thirteen days after the patch, security researchers spotted the first exploitation attempts in the wild, associated with a scanner routed through VPN exit nodes.
Why one header is enough
The vulnerability, tracked as CVE-2026-20896 and rated 9.8 out of 10 on the CVSS scale, comes from a default setting baked into Gitea’s Docker images rather than a coding mistake in the application logic itself. The shipped app.ini template hard-codes REVERSE_PROXY_TRUSTED_PROXIES = *, which tells Gitea to trust the X-WEBAUTH-USER header from any source IP address whenever reverse-proxy authentication is enabled.
In practice, that means an attacker who can reach a Gitea container’s HTTP port over the internet can send a single request with the header X-WEBAUTH-USER: admin and be logged in as that administrator, with no password, no session token, and no prior account required. From there, the attacker has read and write access to every repository on the instance, including private ones, along with SSH keys, CI/CD configuration, and any secrets that developers have committed by accident, such as API keys, database credentials, and deploy tokens.
A pattern, not a one-off
This is the second major Gitea vulnerability to surface in a matter of months. In May, CVE-2026-27771 exposed private container images to unauthenticated pulls across more than 30,000 Gitea deployments, a flaw that had gone undetected for close to four years. That earlier issue lived in the registry API’s access control logic. This one lives in a Docker packaging default that most administrators never think to inspect after initial setup. Together, they point to the same underlying lesson: self-hosted platforms accumulate risk in places well outside the parts of the configuration that teams routinely review.
Gitea and its fork Forgejo remain popular choices across Europe precisely because they let organisations keep source code, CI/CD pipelines, and secrets on infrastructure they control, often for data residency reasons tied to GDPR or sector-specific regulation. That control is only worth as much as the operational discipline behind it. A default reverse-proxy trust setting shipped in a container image undermines the case for self-hosting just as effectively as a cloud provider outage would.
What to do now
The fix in 1.26.3 and later makes reverse-proxy authentication explicitly opt-in, so it no longer activates purely because a trusted proxy list is configured. Any Gitea Docker deployment still on a version prior to 1.26.3 should be upgraded immediately, and administrators should not assume a reverse proxy in front of the container provides adequate protection on its own, since the flaw is in what Gitea itself chooses to trust.
After patching, review access logs for the presence of the X-WEBAUTH-USER header in requests that did not originate from your own reverse proxy, and treat any credentials or tokens stored in repositories as potentially exposed if the instance was reachable from the internet before the upgrade.
If your organisation runs Gitea, Forgejo, or another self-hosted Git platform and needs a security review of the full deployment, including the Docker packaging defaults that vendor documentation rarely highlights, contact Excello Digital. We help European engineering teams keep the control that self-hosting promises without inheriting the risks that come with it.