Thirteen days after public disclosure, security researchers observed the first in-the-wild probe against CVE-2026-20896, a critical Gitea Docker image flaw scored 9.8, according to reporting by The Hacker News and analysis from Sysdig.
How the vulnerability operates inside Gitea Docker images
The flaw stems from Gitea's Docker images shipping an "app.ini" template that hard-codes REVERSE_PROXY_TRUSTED_PROXIES = * by default. The "app.ini" file is described as a core configuration file for managing server parameters, database connections, security behavior, and application settings. That wildcard entry effectively trusts the X-WEBAUTH-USER header from any source IP address.
When an administrator enables reverse-proxy authentication — setting ENABLE_REVERSE_PROXY_AUTHENTICATION = true — Gitea will accept an X-WEBAUTH-USER HTTP header from any client that can reach the container's HTTP port. As security researcher Ali Mustafa, who discovered and reported the flaw, explained: "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 be authenticated as any user, with no password and no token." Mustafa also warned that "With auto-registration on, an admin username gives admin."
Gitea's advisory underscores the risk: "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," and it calls out "Admin accounts (admin, gitea_admin, etc.)" as obvious targets.
Scope: affected versions, the patch, and exposed instances
The vulnerability is tracked as CVE-2026-20896 and carries a CVSS score of 9.8. It affects Gitea Docker images versions before and including 1.26.2. The issue was addressed in version 1.26.3, released late last month; that release removes the "*" wildcard and makes reverse-proxy authentication opt-in.
Sysdig and other observers estimate there are about 6,200 internet-facing Gitea instances. Given that population and the ability to authenticate as any known or guessable login name via a crafted header, exposed instances with the unpatched Docker image and reverse-proxy login enabled are high-value targets.
Sysdig's detection: an initial probe from a ProtonVPN IP
Cloud security company Sysdig reported it detected the first in-the-wild exploitation attempt 13 days after the vulnerability was publicly disclosed. Michael Clark, senior director of threat research at Sysdig, told The Hacker News: "So far, the activities have been related to initial investigation by the threat actor."
Sysdig observed the first action originating from an IP associated with the ProtonVPN service, 159.26.98[.]241. Clark added that the activity "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."
What this means for system administrators, enterprises, and adversaries
- System administrators and security teams: Instances running Gitea Docker images before and including 1.26.2 that have ENABLE_REVERSE_PROXY_AUTHENTICATION enabled should prioritize upgrading to 1.26.3. The published fix removes the "*" wildcard and makes reverse-proxy authentication opt-in. The advisory also notes the documented safe value for REVERSE_PROXY_TRUSTED_PROXIES is "127.0.0.0/8,::1/128" (localhost / loopback), rather than the wildcard.
- Affected enterprises and procurement leaders: With roughly 6,200 internet-facing instances identified, organizations that deploy Gitea in Docker containers should inventory exposed services and confirm whether the app.ini template was modified or left at its default. The presence of auto-registration and known admin usernames increases the severity described by the advisory.
- Adversaries and opportunistic actors: The observed activity so far has been characterized as initial investigation; the vulnerability directly enables unauthenticated header-based user impersonation, creating a low-effort path to account takeover when the default Docker configuration is present.
Conclusion: patch now, questions remain about exposure
The facts are simple and urgent: a default Docker configuration in Gitea containers made it possible for unauthenticated clients to claim any user's identity via the X-WEBAUTH-USER header; the issue was fixed in 1.26.3; and probing was seen in the real world 13 days after disclosure. As the original reporting notes, "Given the severity of the issue, it's essential that users apply the fixes as soon as possible for optimal protection."
What remains to be tracked is whether probes escalate into confirmed account takeovers and how many of the estimated 6,200 internet-facing instances will be updated promptly. For now, administrators should assume exposure is possible until upgrades or configuration changes are applied.
Original reporting: Threat Actors Probe Gitea Docker Flaw CVE-2026-20896 13 Days After Disclosure — The Hacker News
