CVE-2026-20896 carries a CVSS score of 9.8, rated Critical, and it’s now being actively exploited against self-hosted Gitea instances that run the project’s official Docker image. The bug lets an attacker log in as any user, admin accounts included, without a password, a token, or a session cookie. Gitea’s maintainers fixed it in versions 1.26.3 and 1.26.4, released June 20 and 21, 2026 (official announcement).
The Root Cause: A Hardcoded Wildcard
The bug sits in the app.ini configuration template shipped inside the official gitea/gitea Docker image on Docker Hub and GHCR. That template sets REVERSE_PROXY_TRUSTED_PROXIES = *, instead of the documented, safe default of 127.0.0.0/8,::1/128 (loopback only). So Gitea ends up trusting the X-WEBAUTH-USER HTTP header, which is meant to be set only by a reverse proxy that has already verified who the user is, from any source IP that can reach the container. Not just from the proxy in front of it. The full technical writeup is in the official GitHub Security Advisory GHSA-f75j-4cw6-rmx4.
How the Bypass Actually Works
If your Gitea container’s port is reachable, whether directly, through a misconfigured firewall rule, or from another container on the same Docker network, an attacker doesn’t need to touch your reverse proxy at all. They send a request straight to Gitea with a forged X-WEBAUTH-USER: admin header (or gitea_admin, or whatever account name they’re guessing) and Gitea logs them in as that user. No password. No token. No cookie. Turn on ENABLE_REVERSE_PROXY_AUTO_REGISTRATION too, and an attacker doesn’t even need to guess a valid username; they can just create a new account on the spot.
Who Is Actually Affected
Worth getting right, since it’s easy to overstate. The bug only hits installations meeting all three of these conditions:
- Running the official Docker image (
gitea/giteafrom Docker Hub or GHCR), not a binary release and not a self-compiled build - On version 1.26.2 or earlier
- With
ENABLE_REVERSE_PROXY_AUTHENTICATION=trueset, which is common for anyone pairing Gitea with Authentik, Authelia, or another SSO / reverse-proxy authentication layer
Installed Gitea from a binary release, or compiled it yourself following the documented app.example.ini? You’re fine. Those paths inherit the safe, loopback-only default and were never exposed to this bug. Only the official Docker image’s baked-in template shipped with the wildcard.
One clarification worth adding: Forgejo, the community fork of Gitea, runs its own independent release and security process. We haven’t found a primary source confirming whether CVE-2026-20896 applies to Forgejo one way or the other, so we’re not going to guess here. Forgejo users should check that project’s own advisories directly.
Active Exploitation Is Already Happening
Researcher rz1027 found and responsibly disclosed the flaw, credited on the advisory published June 21, 2026. Real-world exploitation followed fast. Michael Clark, Sr. Director of Threat Research at Sysdig, reported the first observed exploitation attempt just 13 days after the advisory went public, around July 4, 2026, traced to a scanner routed through a VPN exit node. Security Affairs covered it on July 7, BleepingComputer on July 10. Shodan and Sysdig data put roughly 6,200 Gitea instances publicly reachable on the internet right now, though nobody knows how many of those are actually running the vulnerable Docker configuration. Singapore’s Cyber Security Agency has also put out a public alert about the active exploitation.
How to Protect Your Instance
Update to Gitea 1.26.4, or 1.26.3 at minimum. Reverse-proxy authentication is opt-in now; an admin has to configure it explicitly instead of Gitea trusting a wildcard by default. One thing worth flagging: 1.26.3 wasn’t a narrow, single-issue patch. It bundled fixes for eight other CVEs in the same release, including SSRF hardening, a TOTP replay fix, and an LFS authentication bypass over SSH. Running Gitea in Docker? This is a good moment to update the whole stack, not just patch around this one bug.
Can’t update right away? Set REVERSE_PROXY_TRUSTED_PROXIES to your actual reverse proxy’s IP address, never a wildcard, and go check your Gitea access logs for anything odd involving the X-WEBAUTH-USER header.
Running Gitea’s official Docker image behind a reverse proxy? See our Gitea setup guide, and check your version now.