Zerodayhub

TL;DR: A single spoofed HTTP header is enough to log in as any user — including an admin — on internet-facing Gitea servers running the official Docker image with reverse-proxy authentication enabled. Sysdig detected the first real-world exploitation attempt 13 days after public disclosure. If you self-host Gitea via Docker, patch to 1.26.4 now.

Key takeaways

• CVE-2026-20896 is a CVSS 9.8 (Critical) authentication bypass in the official Gitea Docker image, tracked under CWE-284 (Improper Access Control).
• The image ships with REVERSE_PROXY_TRUSTED_PROXIES=* by default. Combined with reverse-proxy authentication, this lets an unauthenticated attacker send a single X-WEBAUTH-USER header and be logged in as whoever they claim to be — including admin.
• Sysdig confirmed the first in-the-wild exploitation attempt 13 days after the GitHub security advisory went public, originating from a ProtonVPN exit node.
• Around 6,200 Gitea instances are exposed to the public internet (Shodan), though the number running the vulnerable default configuration is unconfirmed.
• Fixed in Gitea 1.26.3 and 1.26.4 (1.26.4 also resolves a regression introduced by the 1.26.3 fix) — upgrade straight to 1.26.4.
• A public proof-of-concept and detector script is already circulating on GitHub, so exploitation is well within reach of opportunistic scanners, not just sophisticated actors.

What is CVE-2026-20896?

CVE-2026-20896 is a critical authentication bypass affecting the official Docker image for Gitea, the popular open-source, self-hosted alternative to GitHub and GitLab used for source control, pull requests, CI/CD and team collaboration. The flaw was discovered and reported by security researcher Ali Mustafa (@rz1027) and published as GitHub security advisory GHSA-f75j-4cw6-rmx4.

The root cause is a misconfigured default: Gitea’s official Docker image ships with REVERSE_PROXY_TRUSTED_PROXIES hard-coded to * instead of the documented safe value of 127.0.0.0/8,::1/128 (loopback only). Gitea supports authenticating users via a reverse proxy that sets an X-WEBAUTH-USER header — but it’s only supposed to trust that header when it comes from a proxy on the trusted list. With the wildcard in place, every source IP is treated as trusted, so the allowlist check is effectively meaningless. Any client that can reach the container’s HTTP port directly, bypassing the intended reverse proxy, can set the header itself.

This only bites when an administrator has enabled reverse-proxy authentication (ENABLE_REVERSE_PROXY_AUTHENTICATION=true) — a common setup for organisations that front Gitea with SSO or an authenticating gateway. Standard Gitea installs that don’t use this feature, or self-built (non-Docker) deployments using the secure default, are not affected.

How the Gitea exploit works

In plain terms: if reverse-proxy login is switched on, anyone who can reach the Gitea container on the network can pretend to be any user just by including one HTTP header in their request — no password, no token, no session cookie.

Mechanically:

• Root cause: The official Docker image’s bundled app.ini template sets REVERSE_PROXY_TRUSTED_PROXIES = *, disabling the IP allowlist that is meant to restrict which upstream proxies Gitea will trust for identity headers.
• What the attacker sends: A single HTTP request to the Gitea container with an X-WEBAUTH-USER header set to a known or guessable username — admin and gitea_admin are the obvious targets.
• What they get: If auto-registration is enabled, an unrecognised username in the header can even create a new authenticated account on the fly. If the username matches an existing account (including an admin account), the attacker is logged in as that user with full privileges — no credentials required.
• Pre-conditions: The Gitea container’s HTTP port must be reachable by the attacker directly (i.e. not exclusively behind the intended authenticating proxy), and ENABLE_REVERSE_PROXY_AUTHENTICATION must be set to true.

Notably, Gitea’s advisory states that this bypass also defeats MFA in some configurations, because technicians/users can self-register their own MFA method on first login — meaning an attacker who impersonates a fresh account can enrol their own second factor.

Illustrative (non-operational) request pattern:

GET /  HTTP/1.1
Host: gitea.internal.example.com
X-WEBAUTH-USER: admin

Is CVE-2026-20896 actively exploited?

Yes. Cloud security firm Sysdig confirmed the first in-the-wild exploitation attempt against the flaw 13 days after the public advisory. Michael Clark, Sysdig’s Senior Director of Threat Research, said sensors caught “the first in-the-wild hit… a VPN-exit scanner that grabbed access,” originating from a ProtonVPN exit node (IP 159.26.98[.]241). As of Sysdig’s reporting, the observed activity was limited to initial reconnaissance rather than confirmed data theft or follow-on compromise — but Clark noted this is likely because the activity was caught early, “before it has had the chance to develop beyond that initial phase.”

Singapore’s Cyber Security Agency (CSA) also issued an advisory (AL-2026-083) warning organisations about active exploitation of CVE-2026-20896 and recommending immediate mitigation.

A public proof-of-concept and detector script authored by the discovering researcher is available on GitHub (rz1027/CVE-2026-20896), which lowers the bar for opportunistic scanning considerably.

As of 14 July 2026, ZeroDayHub could not confirm CVE-2026-20896 has been added to the CISA Known Exploited Vulnerabilities (KEV) catalogue — unlike several other vulnerabilities added to KEV in the same week (Adobe ColdFusion CVE-2026-48282, Joomla/Joomlack Page Builder flaws, and Langflow). We’ll update this post if that changes.

Sysdig estimates roughly 6,200 Gitea instances are exposed to the public internet via Shodan, though it’s not known how many are running the vulnerable default configuration with reverse-proxy authentication enabled.

How to fix CVE-2026-20896: remediation & mitigation

Patch: Upgrade the official Gitea Docker image to 1.26.4. Gitea released 1.26.3 first to make reverse-proxy authentication opt-in and remove the wildcard trust, then shipped 1.26.4 shortly after to fix a regression introduced by the 1.26.3 change — go straight to 1.26.4 rather than stopping at 1.26.3.

If you can’t patch immediately:

• Explicitly set REVERSE_PROXY_TRUSTED_PROXIES to the specific IP address(es) or CIDR range of your actual trusted reverse proxy — never leave it as the wildcard *.
• If you don’t need reverse-proxy authentication, disable it (ENABLE_REVERSE_PROXY_AUTHENTICATION=false).
• Ensure the Gitea container’s HTTP port is not directly reachable from outside your trusted network — route all traffic exclusively through the intended authenticating proxy, and firewall the container’s port from direct external access.
• Disable auto-registration via reverse-proxy headers if it isn’t required.

After patching:

• Rotate credentials and API tokens for any accounts that may have been impersonated, especially administrator accounts.
• Terminate all active sessions for admin and service accounts to invalidate any session an attacker may have established.
• Review repository access logs, deploy keys, and CI/CD configuration for unauthorised changes, since a successful bypass grants read/write access to source code and secrets.
• Audit for newly created or newly enrolled MFA methods on accounts you didn’t provision yourself, given the self-enrolment weakness noted in the advisory.

Detection / IOCs:

• Review Gitea and reverse-proxy access logs for requests to the Gitea HTTP port that arrive directly rather than via your proxy tier, and for X-WEBAUTH-USER headers you didn’t set.
• Sysdig’s published indicator: reconnaissance traffic originating from ProtonVPN exit node 159.26.98[.]241. Treat this as a single historical data point, not a complete blocklist — attackers will rotate infrastructure.
• Look for logins to admin/gitea_admin-style accounts with no corresponding password authentication event in your identity provider logs.

Frequently asked questions

Does this affect all Gitea installations?
No. Only the official Gitea Docker image, running versions up to and including 1.26.2, with reverse-proxy authentication enabled and the default trusted-proxies wildcard left in place. Standard installs, self-built binaries, and Docker deployments that don’t use reverse-proxy authentication are not affected by this specific flaw.

Do I need to expose Gitea to the internet for this to matter?
Direct internet exposure makes exploitation trivial, but any attacker who can reach the container’s HTTP port on your internal network — including a compromised host inside your perimeter — can exploit it too. Don’t treat this as a “public-facing only” problem.

What can an attacker actually get?
Full impersonation of any user they can name, up to and including admin. That translates to read/write access to private repositories, exposure of secrets accidentally committed to code (API keys, database credentials, deploy tokens), and the ability to tamper with CI/CD pipelines.

Is there a working exploit available?
A public proof-of-concept and detector script exists on GitHub from the researcher who reported the flaw. We have not included exploit code in this post.

Sources & further reading

• The Hacker News — Threat Actors Probe Gitea Docker Flaw CVE-2026-20896 13 Days After Disclosure
• BleepingComputer — Hackers exploit critical auth bypass in Gitea Docker image
• Security Affairs — Critical Gitea Docker Bug Under Active Exploitation Exposes Repositories and Secrets
• GitHub Security Advisory GHSA-f75j-4cw6-rmx4 — go-gitea/gitea
• Gitea Blog — Release of 1.26.3 and 1.26.4
• CVE Record — CVE-2026-20896 (cve.org)
• Singapore CSA Alert AL-2026-083 — Critical Vulnerability in Gitea Docker
• rz1027/CVE-2026-20896 — Public PoC and detector (GitHub)

ZeroDayHub tracks critical vulnerabilities as they break. Subscribe for updates.