CVE-2026-20896 Overview
CVE-2026-20896 is an access control weakness [CWE-284] affecting the official Gitea Docker image up to and including version 1.26.2. The image ships with REVERSE_PROXY_TRUSTED_PROXIES=* configured by default. This wildcard tells Gitea to trust reverse-proxy authentication headers from any source address. When operators enable header-based authentication such as X-WEBAUTH-USER, any network-reachable attacker can inject that header and impersonate any account, including administrators. The flaw is fixed in Gitea 1.26.3 and 1.26.4.
Critical Impact
Unauthenticated network attackers can impersonate arbitrary Gitea users, including administrators, when reverse-proxy header authentication is enabled.
Affected Products
- Gitea Docker image versions up to and including 1.26.2
- Deployments using reverse-proxy authentication headers such as X-WEBAUTH-USER
- Containers running with the default REVERSE_PROXY_TRUSTED_PROXIES=* setting
Discovery Timeline
- 2026-07-03 - CVE-2026-20896 published to the National Vulnerability Database (NVD)
- 2026-07-07 - CVE-2026-20896 last updated in NVD
Technical Details for CVE-2026-20896
Vulnerability Analysis
Gitea supports delegating authentication to an upstream reverse proxy. When enabled, Gitea reads a configured header, typically X-WEBAUTH-USER, and treats its value as the authenticated identity. To prevent header spoofing, Gitea uses the REVERSE_PROXY_TRUSTED_PROXIES setting to define which source addresses are permitted to supply that header.
The official Gitea Docker image sets REVERSE_PROXY_TRUSTED_PROXIES=* by default. The wildcard instructs Gitea to accept the authentication header from any client address. Operators who enable reverse-proxy authentication without overriding this default expose the login mechanism to direct clients, not only to their trusted proxy.
The result is authentication bypass through header injection. An attacker who can reach the Gitea HTTP endpoint sends a request containing X-WEBAUTH-USER: admin and is authenticated as that user. No credentials, tokens, or prior session are required.
Root Cause
The root cause is an insecure default configuration. The trusted-proxy allowlist is set to a wildcard in the container image rather than to loopback or a documented proxy range. The fix in pull request 38151 tightens the default so that arbitrary source addresses are no longer trusted for header-based authentication.
Attack Vector
Exploitation is network-based and requires no authentication or user interaction. An attacker sends an HTTP request to the Gitea instance and adds the configured reverse-proxy header with the username of the target account. Gitea processes the header, establishes a session bound to the impersonated user, and grants full application privileges associated with that account. Details of the specific header names and configuration keys are documented in the GitHub Security Advisory GHSA-f75j-4cw6-rmx4 and the Gitea Pull Request Update.
Detection Methods for CVE-2026-20896
Indicators of Compromise
- HTTP requests to Gitea containing X-WEBAUTH-USER, X-Forwarded-User, or similar reverse-proxy authentication headers originating from addresses outside the documented proxy tier.
- Gitea audit log entries showing administrative actions from sessions that did not perform an interactive login.
- New SSH keys, personal access tokens, or webhooks created on privileged accounts without a corresponding login event.
Detection Strategies
- Inspect the running configuration for REVERSE_PROXY_TRUSTED_PROXIES=* combined with ENABLE_REVERSE_PROXY_AUTHENTICATION=true in app.ini or container environment variables.
- Compare source IPs of requests carrying reverse-proxy auth headers against the known reverse-proxy address range and alert on mismatches.
- Correlate Gitea authentication events with upstream proxy access logs to identify sessions that never traversed the proxy.
Monitoring Recommendations
- Forward Gitea application logs and reverse-proxy access logs to a central analytics platform for cross-source correlation.
- Alert on privileged account activity, such as repository permission changes or admin panel access, that lacks a matching upstream proxy request.
- Track creation of access tokens and SSH keys on administrator accounts and require ticket-linked justification.
How to Mitigate CVE-2026-20896
Immediate Actions Required
- Upgrade the Gitea Docker image to 1.26.3, 1.26.4, or later as described in the Gitea Release Announcement.
- Set REVERSE_PROXY_TRUSTED_PROXIES to the specific address or CIDR of the legitimate reverse proxy, for example 127.0.0.1/32 for a sidecar deployment.
- Rotate administrator credentials, personal access tokens, and SSH keys if reverse-proxy authentication was enabled on an exposed instance.
Patch Information
The fix ships in Gitea 1.26.3 and 1.26.4. The relevant change is tracked in the Gitea Release v1.26.3 notes and the Gitea Pull Request Update, which changes the default trusted-proxy configuration.
Workarounds
- Disable reverse-proxy authentication by setting ENABLE_REVERSE_PROXY_AUTHENTICATION=false until the container can be upgraded.
- Restrict network access to the Gitea HTTP port so that only the trusted reverse proxy can reach it, using firewall rules or a container network policy.
- Configure the upstream reverse proxy to strip inbound X-WEBAUTH-USER and related headers from client requests before forwarding.
# Configuration example: restrict trusted proxies to the local reverse proxy
# In app.ini or as container environment variables
ENABLE_REVERSE_PROXY_AUTHENTICATION=true
REVERSE_PROXY_TRUSTED_PROXIES=127.0.0.1/32
REVERSE_PROXY_AUTHENTICATION_HEADER=X-WEBAUTH-USER
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
