Gitea Docker CVE-2026-20896 Exploit: A Single Header Grants Admin Access to Repositories

Sysdig confirmed in a report reissued this week by The Hacker News that CVE-2026-20896 in Gitea Docker has transitioned from a theoretical vulnerability to an active target on the internet. The first attempt at exploitation in production occurred 13 days after the flaw was published, originating from an exit node of ProtonVPN at 159.26.98.241, exhibiting a typical scanning pattern of widespread campaigns: probing for exposed services, attempting bypasses, and collecting responses.

The flaw is egregious in what it allows. The CVSS score reaches 9.8 because the official Docker image shipped with a template app.ini that set REVERSE_PROXY_TRUSTED_PROXIES = *. Combined with the header-based authentication configuration, the server began accepting the X-WEBAUTH-USER header from any IP address and treating it as an authenticated identity. In other words, an unauthenticated client from the open internet could present itself as any Gitea user, including admin, without needing a password, SSH key, or token.

What is Exposed

Sysdig counts approximately 6,200 Gitea instances exposed to the internet at the time exploitation began appearing. Not all of this base is running the vulnerable Docker image, but the impacted subset includes exactly the profile that most interests criminal operators: medium-sized internal development teams, startup code servers, corporate labs that preferred self-hosting over using GitHub or GitLab, and managed providers that packaged Gitea in containers for resale.

The content of these repositories is often worth more than the code itself. CI/CD private keys, cloud tokens, bank credentials in configuration files, infrastructure as code definitions with internal endpoints, data notebooks, and commit history with sensitive data that has been reverted and never purged appear in most self-hosted environments that have not undergone formal auditing. Admin access to Gitea provides visibility into all the organization's private repos without generating a standard authentication log, because the server genuinely believes the request is legitimate.

How It Reached Its Current State

The vulnerability was disclosed by Gitea maintainers alongside release 1.26.3, advising administrators to update immediately or remove the line REVERSE_PROXY_TRUSTED_PROXIES = * from the app.ini file. According to Sysdig, this 13-day window between publication and the first observed attempt follows the average that the company has been measuring in N-day campaigns: public bots consume the CVE feed, generate scanning signatures, and trigger mass scans, often before internal teams have finished inventorying affected instances.

The fact that the exploit originated from a ProtonVPN node does not indicate specific authorship. It’s common practice in opportunistic reconnaissance campaigns, and Sysdig noted that, by the time of the report, there were no confirmed reports of successful post-exploitation or leaks directly attributed to the flaw. This is not comforting: the interval between scan and usage is often measured in hours when the exploit works like in this case, without the need for sophisticated payloads.

What to Do Now

For Gitea Docker operators, the playbook is short and urgent. Update to 1.26.3, remove or restrict REVERSE_PROXY_TRUSTED_PROXIES to truly trusted ranges, review access logs from the past two weeks for requests with unexpected X-WEBAUTH-USER, and enforce rotation of any credentials that appear in plain text within private repos. Teams exposing Gitea via public ingress without a WAF in front should treat the instance as compromised until proven otherwise, especially if the version is behind 1.26.3 by more than a few days.

The case illustrates a repeating pattern in DevOps products: a default configuration designed to facilitate internal deployment transforms into an open door when the same image is deployed in production with public exposure. The REVERSE_PROXY_TRUSTED_PROXIES = * makes sense in an environment where only a known reverse proxy communicates with the container. Leaving this value as the default in an official image distributed for unforeseen scenarios is the type of engineering choice that typically ends in critical CVEs. The swift response from the Gitea team addresses the flaw, but the lesson for those managing fleets of containers is that the security review must occur before the pull, not after the first alert.