CVE-2026-20896 is the kind of vulnerability that makes you look twice. A remote attacker can gain full administrative access to a self-hosted Gitea instance by sending a single HTTP header. No credentials. No token. No second factor. Just one header, injected into any request, and the server treats the attacker as any user they name.
How the vulnerability works
Gitea's Docker images before version 1.26.3 shipped with a default configuration that set REVERSE_PROXY_TRUSTED_PROXIES to the wildcard value *. This setting tells Gitea to trust the X-WEBAUTH-USER HTTP header from any source IP as the identity of the authenticated user. When Gitea is configured this way, anyone on the internet can send a request with that header set to any username they choose, including administrator accounts, and Gitea will treat the request as authenticated for that user.
The wildcard was introduced because Docker images often sit behind a reverse proxy, and it was convenient to allow any proxy to pass through user identity. The problem is that many Gitea Docker deployments are not behind a strict reverse proxy, or the proxy does not filter the X-WEBAUTH-USER header before forwarding requests. In those configurations, the bypass works from anywhere on the internet.
What attackers can access
A Gitea instance is a development organization's source of truth. Gaining administrative access exposes everything the organization has committed, including private repositories, CI/CD pipeline configurations, and any secrets that developers left in code or configuration files. Typical finds include:
- API keys and service account credentials committed to configuration files.
- Database connection strings and credentials in application configuration files.
- Deploy keys and webhook secrets providing access to production infrastructure.
- CI/CD workflow definitions that can be modified to inject malicious build steps.
Active probing is underway
Thirteen days after CVE-2026-20896 was publicly disclosed, researchers observed active probing in the wild. The initial reconnaissance was traced to a ProtonVPN exit node using automated scanning to identify open HTTP and HTTPS ports, fingerprint Gitea deployments, and then attempt the X-WEBAUTH-USER header injection. The pattern is consistent with opportunistic automated exploitation scanning. Targeted exploitation of interesting repositories found during the scan may follow.
What you should do
- Upgrade to Gitea 1.26.3 or later. The fix removes the wildcard REVERSE_PROXY_TRUSTED_PROXIES default and makes reverse-proxy authentication opt-in.
- Check your REVERSE_PROXY_TRUSTED_PROXIES configuration. If running a version prior to 1.26.3, verify whether this is set to * and restrict it to an explicit allowlist of known trusted proxy IP addresses.
- Audit access logs. Review authentication events for accounts that do not correspond to known users, particularly for administrative accounts.
- Rotate exposed secrets. If unauthorized access is possible, rotate all API keys, deploy tokens, and database credentials stored in any hosted repository.
The wider lesson is that Docker image default configurations are a security attack surface in their own right. A wildcard trusted proxy setting is an antipattern that appears in other Docker-deployed web applications beyond Gitea. The convenience defaults that make containers easy to deploy are often not the same as the security-appropriate defaults that belong in production.
Gigia Tsiklauri is a Security Architect and founder of Infosec.ge. Get in touch if your team is reviewing self-hosted developer tooling security or container hardening practices.