CVE-2026-20896: Gitea Docker Auth Bypass—Scans Started Within Two Weeks
Hey everyone,
Just caught the Sysdig report regarding CVE-2026-20896. If you’re running Gitea in Docker, you need to check your headers immediately.
This is a nasty one (CVSS 9.8). The vulnerability stems from the application blindly trusting the X-WEBAUTH-USER header from any IP address. Essentially, if your reverse proxy isn't configured to strip this specific header, an unauthenticated attacker on the internet can inject any username they want and gain administrative access to your Git repositories.
The scary part is that threat actors were already probing for this just 13 days after the PoC dropped.
Detection Logic You can check if you were targeted by grepping your ingress logs for the specific header. If you see requests with this header that didn't originate from your trusted internal proxy, you might have a problem.
grep "X-WEBAUTH-USER" /var/log/nginx/gitea_access.log | awk '{print $1}' | sort -u
Alternatively, here is a quick Python snippet to validate if your instance is exploitable before patching:
import requests
target = "http://your-gitea-instance/"
headers = {"X-WEBAUTH-USER": "root"}
response = requests.get(target, headers=headers)
if response.status_code == 200 and "root" in response.text:
print("[!] VULNERABLE: Header authentication bypass successful.")
else:
print("[+] Safe or patched.")
**Mitigation**
Ensure you are running the latest patched Docker image and, crucially, that your ingress controller (Nginx/Traefik) is dropping unauthorized X-WEBAUTH-USER headers from external requests.
How many of you are still running self-hosted Gitea behind cloudflared or similar tunnels without strict header filtering?
Good catch. We use Traefik forward auth in our environment. I had to explicitly add a middleware to strip this header because the upstream documentation was vague about which headers were safe. If anyone needs the Traefik dynamic config snippet to drop incoming headers, let me know. It's a one-liner but easy to miss.
From a SOC perspective, this is high-fidelity. We whipped up a Sigma rule last night that looks for the presence of that header in HTTP streams. Since legitimate traffic shouldn't be sending X-WEBAUTH-USER to the container from the outside internet, false positives have been near zero. Highly recommend adding this to your SIEM if you can't patch immediately.
This highlights the danger of implicit trust in internal headers. It’s the same issue we saw with the Cloudflare OAuth bypass a few years back. If you're exposing Docker containers directly without a properly configured WAF or reverse proxy acting as a sanitization layer, you're basically inviting trouble. We pushed a Trivy scan to our CI/CD pipeline to catch old image tags immediately.
Excellent points, Amy and Joe. From an IAM standpoint, we must also verify the internal Gitea configuration. If ENABLE_REVERSE_PROXY_AUTHENTICATION is enabled in app.ini without strict IP allow-listing in REVERSE_PROXY_TRUSTED_PROXIES, the application accepts the header regardless of external proxy rules.
You can audit your running containers with this command:
docker exec grep -E "ENABLE_REVERSE_PROXY|TRUSTED_PROXIES" /data/gitea/conf/app.ini
If `TRUSTED_PROXIES` is empty while auth is enabled, treat it as compromised.
The scanning traffic mentioned in the title is ramping up fast. For those needing to quickly validate if their current config hardening is effective, try this non-destructive curl test:
curl -s -o /dev/null -w "%{http_code}" -H "X-WEBAUTH-USER: administrator" https://your-gitea-url.com/
A `200` response without credentials means you need to review your reverse proxy config immediately.
Good discussion. To complement the external validation, don't forget to audit the running container's configuration. Misconfigurations can slip through during updates. You can verify the app.ini inside the container to ensure reverse proxy auth isn't inadvertently active:
docker exec grep -E "ENABLE_REVERSE_PROXY|X-WEBAUTH" /data/gitea/conf/app.ini
If `ENABLE_REVERSE_PROXY_AUTHENTICATION` is enabled but your proxy stripping fails, that's the failure point. Always verify both sides of the fence.
I’ve already spotted chatter on underground markets claiming modules for this CVE are integrating into standard mass-scan toolkits. To complement the Sigma rule, ensure your WAF is dropping this specific header explicitly. A quick ModSecurity rule would look like this:
apache
SecRule REQUEST_HEADERS:X-WEBAUTH-USER "@rx .*"
"id:100123,phase:1,deny,status:403,msg:'Gitea Auth Bypass Attempt'"
This ensures it never reaches the upstream container, regardless of the Gitea config.
As an MSP, checking configs on dozens of nodes is a pain. To quickly audit if ENABLE_REVERSE_PROXY_AUTHENTICATION is active across your fleet via environment variables, run this:
docker ps --filter "ancestor=gitea/gitea" --format "{{.Names}}" | xargs -I {} sh -c 'echo "Container: {}" && docker inspect {} --format "{{range .Config.Env}}{{println .}}{{end}}" | grep REVERSE_PROXY || echo "Not set via ENV"'
This helps identify which containers need immediate app.ini checks for those IP allow-lists Yuki mentioned.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access