Critical Gitea Docker Authentication Bypass Under Active Probing: CVE-2026-20896

A critical authentication bypass vulnerability, tracked as CVE-2026-20896, has been disclosed in the official Gitea Docker image. Gitea is a self-hosted software development platform used for Git hosting, code review, collaboration, package registry, and CI/CD workflows.

The vulnerability carries a CVSS v3.1 score of 9.8 and affects Gitea Docker images up to and including version 1.26.2 when reverse-proxy authentication is enabled. 

Vulnerability Overview

CVE-2026-20896 is not a traditional memory corruption or remote code execution vulnerability. Instead, it is an authentication trust boundary failure caused by an unsafe default configuration in the official Gitea Docker image.

Gitea supports reverse-proxy header authentication, where a trusted upstream proxy authenticates the user and forwards the identity to Gitea using headers such as X-WEBAUTH-USER. In secure deployments, Gitea should only trust those headers when they come from known reverse proxy IP addresses. Gitea’s documentation states that reverse-proxy authentication is not enabled by default and that REVERSE_PROXY_TRUSTED_PROXIES defaults to loopback ranges such as 127.0.0.0/8,::1/128.

However, the vulnerable Docker image template hard-coded the trusted proxy value as:

REVERSE_PROXY_TRUSTED_PROXIES = *

This wildcard causes Gitea to treat requests from any source IP as trusted for reverse-proxy authentication purposes. When ENABLE_REVERSE_PROXY_AUTHENTICATION = true is also enabled, an attacker can send a crafted request containing an arbitrary username in the X-WEBAUTH-USER header. Gitea then accepts the supplied identity without requiring a password, token, or valid session.

Affected Products and Conditions

The vulnerability affects:

• Official gitea/gitea Docker images
• Versions up to and including 1.26.2
• Deployments where reverse-proxy authentication is enabled
• Deployments where the Docker image default or equivalent wildcard trusted-proxy configuration remains in place

The Gitea advisory notes that binary distributions and self-built deployments following app.example.ini are not affected by this specific Docker image default, because they use the loopback-only trusted proxy setting.

The issue was addressed in Gitea 1.26.3, while Gitea’s release notes recommend upgrading directly to 1.26.4 because 1.26.4 fixed a regression introduced in 1.26.3 and included an additional security fix.

Exploitation Path

The attack path is simple and low-friction:

1. The attacker identifies a reachable Gitea Docker instance.
2. The attacker determines or guesses a valid username, such as admin, administrator, or a known developer account.
3. The attacker sends an HTTP request containing a spoofed reverse-proxy authentication header.
4. Gitea accepts the spoofed identity because the trusted proxy configuration allows any source IP.
5. The attacker gains access as the impersonated user.

If the impersonated account is an administrator, the attacker may gain full control over the Gitea instance. If reverse-proxy auto-registration is enabled, the same flaw may allow attacker-controlled account creation.

Security researcher Ali Mustafa, credited as one of the reporters, published a public write-up and detector after the issue was patched. The write-up confirms that the bypass affects web sessions, not the token API, and that remediation is to upgrade or explicitly restrict trusted proxy IPs.

Threat Activity and Exposure

Public reporting indicates that threat actors have started probing for CVE-2026-20896. The first observed in-the-wild attempt occurred 13 days after public disclosure. The reported activity was described as early-stage investigation rather than a fully developed post-exploitation campaign, with the first observed source linked to ProtonVPN infrastructure at 159.26.98[.]241.

Potential Impact

Successful exploitation may allow an attacker to:

• Access private repositories and sensitive source code
• Impersonate developer or administrator accounts
• Add or modify SSH keys and access tokens
• Create or modify users if auto-registration is enabled
• Change repository settings, webhooks, deploy keys, and integrations
• Access CI/CD secrets, package registry material, and internal documentation
• Tamper with code, releases, or build workflows
• Use repository and CI/CD access for lateral movement into development or production environments

MITRE ATT&CK Mapping

Relevant ATT&CK techniques include:

• T1190 – Exploit Public-Facing Application: Internet-facing Gitea instances may be targeted through the exposed HTTP service. MITRE defines this technique as adversaries exploiting weaknesses in public-facing systems for initial access.
• T1098 – Account Manipulation: If attackers add SSH keys, create accounts, modify permissions, or alter access tokens after impersonation, the activity aligns with account manipulation.
• T1213 / T1213.003 – Data from Information Repositories / Code Repositories: Compromised Gitea repositories may be mined for source code, secrets, infrastructure details, and other sensitive development information.

Detection and Hunting Recommendations

Organizations should review web, reverse proxy, container, and Gitea application logs for suspicious use of reverse-proxy authentication headers. Priority should be given to requests containing:

• X-WEBAUTH-USER
• X-WEBAUTH-EMAIL
• X-WEBAUTH-FULLNAME

These headers should be considered suspicious when they originate from any IP address other than the expected internal reverse proxy.

Defenders should also hunt for:

• Successful sessions for administrative accounts from unusual IP addresses
• Direct access to the Gitea container port, commonly TCP/3000, bypassing the intended reverse proxy
• New or modified administrator accounts
• Unexpected SSH keys added to user accounts
• Newly created personal access tokens
• New webhooks, deploy keys, OAuth applications, or runner registrations
• Bulk repository cloning, archive downloads, or unusual repository browsing
• Changes to CI/CD secrets, package registry settings, or repository visibility
• Login/session activity where no normal authentication event is present

For environments using centralized logging, create detections for any externally sourced HTTP request that includes X-WEBAUTH-USER and reaches Gitea directly. This should be treated as high severity unless the source is a known and approved reverse proxy.

Remediation Guidance

Organizations should take the following actions immediately:

1. Upgrade Gitea Docker deployments to version 1.26.4 or later. Gitea’s own release notes recommend upgrading directly to 1.26.4 rather than remaining on 1.26.3.
2. Review reverse-proxy authentication settings. Confirm whether ENABLE_REVERSE_PROXY_AUTHENTICATION is enabled. If reverse-proxy authentication is not required, disable it.
3. Remove wildcard trusted-proxy configurations. Ensure REVERSE_PROXY_TRUSTED_PROXIES is set only to the actual reverse proxy IP address or CIDR range. Never leave it as *.
4. Restrict direct access to the Gitea HTTP service. The Gitea container port should only be reachable from the reverse proxy or approved internal networks. Internet clients should not be able to reach the backend service directly.
5. Strip identity headers at the edge. Reverse proxies should remove incoming X-WEBAUTH-* headers from untrusted clients and only set them after successful authentication.
6. Conduct a post-exposure audit. If the instance was internet-facing and vulnerable, review users, admin accounts, SSH keys, access tokens, webhooks, deploy keys, CI/CD secrets, runner registrations, and repository changes.
7. Rotate sensitive secrets where compromise cannot be ruled out. This includes deploy keys, CI/CD variables, package registry credentials, webhook secrets, cloud keys, and any credentials stored in repositories.

Stay Safe. Stay Secure.

OP Innovate Research Team