Gitea Under Attack: The Docker Template That Opens the Door to…

It took just 13 days from the advisory's publication for the first in-the-wild exploitation attempts against CVE-2026-20896, a critical vulnerability in Gitea's Docker template that turns a deployment convenience into an authentication bypass achievable with a single HTTP header. Sysdig detected probing from IP address 159.26.98[.]241, a ProtonVPN node, confirming that the patch window for administrators is closing at an unsustainable pace.

It took just 13 days from the advisory's publication for the first in-the-wild exploitation attempts against CVE-2026-20896, a critical vulnerability in Gitea's Docker template that turns a deployment convenience into an authentication bypass achievable with a single HTTP header. Sysdig detected probing from IP address 159.26.98[.]241, a ProtonVPN node, confirming that the patch window for administrators is closing at an unsustainable pace.

The severity is maximum: the National Vulnerability Database assigns CVSS 9.8, with vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Any Gitea instance exposed to the Internet, containerized with official images up to and including version 1.26.2, is potentially impersonable without credentials.

Key Takeaways

The app.ini template in official Gitea Docker images hard-codes REVERSE_PROXY_TRUSTED_PROXIES=*, trusting any IP origin
With ENABLE_REVERSE_PROXY_AUTHENTICATION=true, a remote attacker sends the X-WEBAUTH-USER header and obtains an authenticated session as any user, including admins
Sysdig detected in-the-wild probing on July 6, 2026, 13 days after public disclosure, from an IP associated with ProtonVPN
The fix in Gitea v1.26.3 removes the insecure default and makes reverse-proxy authentication opt-in with explicit administrator configuration

The Mechanism: When the Reverse Proxy Becomes a Backdoor

The vulnerability does not reside in Gitea's source code, but in the configuration template distributed with the official Docker images. The GitHub Security advisory GHSA-f75j-4cw6-rmx4 precisely documents the chain: the preconfigured app.ini file sets REVERSE_PROXY_TRUSTED_PROXIES = *, a wildcard that voids any verification of request origin.

The reverse-proxy authentication pattern is legitimate and widespread: a perimeter proxy handles user authentication and forwards an header attesting to the already-verified identity to the backend. Gitea supports this model with the ENABLE_REVERSE_PROXY_AUTHENTICATION directive, typically enabled by administrators deploying behind nginx, Traefik, or equivalents. The problem: the Docker template defaults to unlimited trust, turning a defensive architecture into an open tunnel.

Researcher Ali Mustafa, known as @rz1027, synthesized the dynamic unequivocally: "With reverse-proxy login enabled, that wildcard trusts every source IP, so anyone who can reach the port can send an X-WEBAUTH-USER header and authenticate as any user, without password and without token." The original advisory adds a relevant operational detail: admin accounts — admin, gitea_admin, and predictable variants — are the obvious targets for compromise.

An escalation path exists. The ENABLE_REVERSE_PROXY_AUTO_REGISTRATION option, when active, allows arbitrary creation of new accounts via forged header, expanding the attack surface beyond impersonation to trust boundary inflation.

Thirteen Days: The Window Closing

The timeline documented by Sysdig via The Hacker News is relentless: public disclosure, the 13-day interval, the first detection. Michael Clark, senior director of threat research at Sysdig, scoped the activity to the initial reconnaissance phase: "So far the activities have been limited to preliminary investigation by the threat actor... Although we recorded the first action from a ProtonVPN service IP, 159.26.98[.]241, it has not yet evolved into exploitation or attack progression."

The distinction between probing and full exploitation is technically relevant but operationally fragile. Probing verifies the presence of the vulnerable condition — an HTTP response consistent with the X-WEBAUTH-USER header being processed — and prepares the ground for the next action. The absence of documented escalation at the time of detection does not imply absence of risk: the ProtonVPN address indicates deliberate origin obfuscation, a pattern consistent with targeted activity rather than indiscriminate scanning.

The exposure data is quantifiable: according to Sysdig estimates reported by The Hacker News, there are approximately 6,200 Internet-reachable Gitea instances. The dossier does not specify how many of these run vulnerable Docker images, nor how many have ENABLE_REVERSE_PROXY_AUTHENTICATION enabled. Uncertainty on the two conditioning factors — version and configuration — prevents precise estimates of the population actually at risk.

The Fix: From Convenience to Explicit Responsibility

Pull request #38151 documents the fix with surgical clarity: "Remove REVERSE_PROXY_LIMIT / REVERSE_PROXY_TRUSTED_PROXIES from Docker app.ini templates (default = * allowed impersonation via X-WEBAUTH-USER; reverse-proxy auth is now opt-in and configured by administrator)."

The architectural choice is significant. The Gitea team did not simply correct the value from wildcard to loopback range — 127.0.0.0/8,::1/128, what the documentation indicates as safe — but eliminated the default from the template entirely, transferring the burden of decision to the administrator. The functionality now requires explicit configuration, removing the "works out of the box" trap that characterized previous images.

According to the official CVE record, the vulnerability affects versions up to and including 1.26.2. The fixed version is 1.26.3, whose changelog reflects the Docker template modification.

"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 (admin, gitea_admin, etc.) are the obvious targets."
— GitHub Security Advisory GHSA-f75j-4cw6-rmx4

Confusion to Avoid: CVE-2026-20896 and CVE-2026-58053

An editor's note appearing on Daily Security Review corrected an initially erroneous association between vulnerabilities. CVE-2026-58053, distinct from the one addressed here, concerns a container escape in Gitea — completely different mechanism, impact, and attack surface. CVE-2026-20896 remains an authentication bypass based on header spoofing, confined to the application layer and conditioned by the specific combination of Docker template and reverse proxy enablement.

The distinction is operational: mitigation measures for a container escape — runtime hardening, seccomp policies, privilege reduction — do not resolve an authentication bypass based on application configuration. Administrators must specifically verify the three elements of the vulnerable chain: Docker image, version ≤1.26.2, presence of REVERSE_PROXY_TRUSTED_PROXIES=* with reverse-proxy authentication enabled.

What to Do Now

Four priority actions emerge from the technical dossier:

Update to Gitea v1.26.3 or later: the official fix removes the insecure default from the Docker template and makes the functionality opt-in
Verify REVERSE_PROXY_TRUSTED_PROXIES configuration on instances that cannot update immediately: if set to *, replace it with the loopback range 127.0.0.0/8,::1/128 or with explicit IPs of authorized proxies
Check logs for probing: search for requests with X-WEBAUTH-USER header from IP addresses not matching legitimate proxies, with particular attention to address 159.26.98[.]241 documented by Sysdig
Disable ENABLE_REVERSE_PROXY_AUTO_REGISTRATION if not strictly necessary, to reduce the escalation surface from impersonation to arbitrary account creation

The Problem of the Insecure Default

CVE-2026-20896 illustrates an underestimated vulnerability category: not the implementation bug, but the deployment decision optimized for convenience. The Docker template is designed to make Gitea work on first boot, without manual intervention; the wildcard resolves every imaginable network scenario, turning the unwitting administrator into a user who has opened an alternative authentication without knowing it.

Reverse-proxy authentication is perceived as a safe pattern because it delegates authentication to a hardened perimeter component. The model breaks not in the proxy, but in the backend's excessive trust: when the origin filter is disabled, the boundary between "legitimate request from proxy" and "arbitrary direct request" dissolves. Gitea v1.26.3 solves the problem by shifting the cost of correct configuration to the deployer, where it should always have been.

For the approximately 6,200 exposed instances, the question is not whether to update, but whether the update will arrive before the probing detected by Sysdig matures into documented compromise. The 13-day window is already closed.

Information verified against cited sources and current as of publication.

Sources

Sources and references