Gitea Auth Bypass CVE-2026-20896 Exploited 13 Days After Patch

Attackers have begun actively scanning for Gitea instances vulnerable to CVE-2026-20896, a critical authentication bypass that allows unauthenticated attackers to impersonate any user—including administrators—by injecting a single HTTP header. The flaw affects Gitea Docker images through version 1.26.2 and was patched in version 1.26.3 released late June.

Initial reconnaissance was traced to a ProtonVPN exit node (159.26.98[.]241), beginning 13 days after public disclosure. Researchers estimate approximately 6,200 Gitea servers were internet-accessible and potentially vulnerable during the initial scanning wave.

How It Works

The vulnerability stems from a default configuration in Gitea's Docker image. Two settings combine to create the flaw: REVERSE_PROXY_TRUSTED_PROXIES defaults to * (trust all connections), and when ENABLE_REVERSE_PROXY_AUTHENTICATION is enabled, Gitea accepts the X-WEBAUTH-USER header as authoritative for user identity.

An attacker can send a request like:

GET /api/v1/user HTTP/1.1
Host: vulnerable-gitea.example.com
X-WEBAUTH-USER: admin

If reverse proxy authentication is enabled and the wildcard trust remains in place, Gitea accepts this as a legitimate authentication from an admin user. No credentials required.

The Hive Security technical analysis notes this is essentially a misconfiguration elevated to vulnerability status because the Docker image's default settings create an insecure deployment out of the box.

What's at Risk

A Gitea administrator can access and modify all repositories in the instance—including private ones. That means:

• Source code for any project hosted on the server
• Secrets developers accidentally committed (API keys, database credentials, deploy tokens)
• CI/CD pipeline configurations that often contain deployment credentials
• Repository deploy keys that may grant access to other systems

For organizations using self-hosted Gitea for sensitive projects, a single exploited instance could expose intellectual property, production credentials, and CI/CD supply chains. The BeyondTrust auth bypass we covered yesterday shows the same pattern: authentication bypass vulnerabilities in self-hosted tools create devastating impact when exploited.

Affected Versions and Fix

The vulnerability affects all Gitea Docker images through version 1.26.2. Version 1.26.3, released in late June, addresses the issue by:

• Removing the * wildcard from the default REVERSE_PROXY_TRUSTED_PROXIES setting
• Making reverse proxy authentication opt-in rather than potentially enabled by default

The fix reached Gitea's official Docker images within the 1.26.3 release. Organizations running older images should upgrade immediately.

Recommended Mitigations

1. Upgrade to Gitea 1.26.3 or later immediately
2. Audit REVERSE_PROXY_TRUSTED_PROXIES and configure specific trusted proxy IPs rather than wildcards
3. Disable reverse proxy authentication if not actively required for your deployment
4. Review repository access logs for any unusual administrative activity
5. Rotate credentials for any secrets stored in repositories on affected instances
6. Check for unauthorized SSH keys or deploy keys added to repositories

If upgrading isn't immediately possible, setting REVERSE_PROXY_TRUSTED_PROXIES to your actual reverse proxy IP addresses rather than * mitigates the attack vector.

Why This Matters

Self-hosted Git platforms are high-value targets. They centralize source code, often contain credential leakage, and typically have access to deployment infrastructure. The 13-day gap between patch availability and active exploitation is longer than we've seen for some vulnerabilities, but scanning has now begun.

Organizations running internet-exposed Gitea instances should treat this as urgent. The exploit requires only a crafted HTTP header—no authentication, no complex payload, no multi-step chain. Once attackers identify vulnerable instances through scanning, exploitation is trivial.

For teams evaluating Git hosting options, this incident reinforces the importance of secure defaults in containerized deployments. Docker images that create vulnerable configurations out of the box shift security responsibility to operators who may not audit every configuration parameter.