security · self-hosting · Docker
Gitea Docker Auth Bypass (CVE-2026-20896): Are You Exposed, and How to Fix It
If you self-host Gitea from its official Docker image, a critical bug needs your attention now. CVE-2026-20896 is an authentication bypass rated CVSS 9.8, and according to reporting from BleepingComputer, The Hacker News and SecurityWeek, it is already under active exploitation in the wild. The good news is that whether you are affected is easy to check, and the fix is a quick upgrade plus one setting.
What the flaw actually is
The problem is an insecure default in the container, not in Gitea's core logic. The official Gitea Docker image ships with REVERSE_PROXY_TRUSTED_PROXIES=*, meaning Gitea trusts the reverse-proxy authentication header X-WEBAUTH-USER from any source IP address. When reverse-proxy authentication is enabled, that header is supposed to come only from a trusted proxy that has already logged the user in. With a wildcard, an unauthenticated client on the internet can simply send the header itself and become whoever it claims to be. That is the whole bypass.
Who is actually affected
Not every Gitea install is at risk. Based on the published advisories, you are exposed if all of these are true: you run the official Gitea Docker image at version 1.26.2 or earlier, you have reverse-proxy authentication headers enabled, and the instance is reachable from the public internet. Installs that do not use reverse-proxy header auth, or that are only reachable on a private network, are not exploitable through this specific path, though upgrading is still the right move.
Why it matters
A Git server is a high-value target. Researchers describe attackers, once past authentication, being able to read private repositories, exfiltrate secrets and source code, create or modify user accounts, and potentially inject malicious changes into CI/CD pipelines that run from those repositories. Sysdig reported catching the first in-the-wild hit within days of the technique becoming known, from automated scanners using VPN-exit nodes. In other words, exposed instances are being found and hit automatically.
How to check and fix it
- Upgrade first. Gitea released 1.26.3 and 1.26.4, which fix the issue. Pull the patched image and redeploy.
- Fix the trusted-proxies setting. Do not leave
REVERSE_PROXY_TRUSTED_PROXIESas*. Set it to the actual IP or subnet of your reverse proxy, so Gitea only trusts the auth header from that source. - Reduce exposure. If a Git server does not need to be on the public internet, put it behind a VPN or firewall. Fewer things exposed means fewer things scanned.
- Check for abuse. After patching, review your Gitea user list and logs for unexpected accounts or access, since exploitation could predate your fix.
The wider lesson
This is a classic "insecure default" failure: the software was fine, but the container shipped with a permissive setting that is dangerous the moment the service faces the internet. Self-hosting is worth it, but it comes with the responsibility to review the defaults of the images you run, especially anything that accepts authentication headers from a proxy. A wildcard trust setting is exactly the kind of default worth auditing before you expose a service.
FAQ
What is CVE-2026-20896? A critical (CVSS 9.8) authentication bypass in the official Gitea Docker image at version 1.26.2 and earlier, caused by trusting the X-WEBAUTH-USER header from any IP. It is under active exploitation.
Am I affected if I do not use reverse-proxy auth? Through this specific path, no. The bypass relies on reverse-proxy authentication headers being enabled. Upgrading is still recommended.
How do I fix it? Upgrade to Gitea 1.26.3 or 1.26.4, and set REVERSE_PROXY_TRUSTED_PROXIES to your real proxy IP instead of a wildcard.
Could I already have been breached? Possibly, if you were exposed before patching. Review user accounts and access logs for anything unexpected.