Gitea Docker Image: Insecure Default Trusted Proxies Configuration Enables Authentication Bypass
Gitea Docker images ship with REVERSE_PROXY_TRUSTED_PROXIES set to '*', allowing any network-accessible attacker to forge X-WEBAUTH-USER headers and impersonate any user when reverse proxy authentication is enabled. This is a configuration-time vulnerability that completely bypasses intended access controls.
CVE References
Affected
Vulnerability Description
This is a configuration-time vulnerability rooted in insecure defaults. Gitea's Docker image template hard-codes REVERSE_PROXY_TRUSTED_PROXIES = *, which instructs the application to trust reverse-proxy identity headers (X-WEBAUTH-USER) from any source IP. This contradicts the documented safe default of 127.0.0.0/8,::1/128 (loopback-only) in the reference configuration. The root cause is a maintenance inconsistency between the Docker template and the application's documentation. The vulnerability is a header-injection identity spoofing attack where an attacker with network access to the container can inject arbitrary values into the X-WEBAUTH-USER header, causing Gitea to treat the attacker as any legitimate user without password verification.
Proof-of-Concept Significance
The PoC demonstrates that this vulnerability is trivially exploitable with a single HTTP header, requires only network connectivity to the container, and works reliably across affected versions. The PoC does not require authentication, reverse-proxy interaction, or sophisticated tooling—any curl-like capability suffices. Preconditions are minimal: (1) Docker image deployment, (2) ENABLE_REVERSE_PROXY_AUTHENTICATION=true set by the administrator, and (3) network access to port 3000. The reliability is 100% because Gitea will parse and trust any X-WEBAUTH-USER header from trusted IPs, which now includes all IPs. This is not a race condition or probabilistic attack.
Detection Guidance
Defenders should monitor for: (1) Configuration auditing: scan app.ini files in running Gitea containers for REVERSE_PROXY_TRUSTED_PROXIES = * combined with ENABLE_REVERSE_PROXY_AUTHENTICATION = true. (2) HTTP request logging: inspect access logs for X-WEBAUTH-USER headers originating from non-proxy source IPs (off-loopback addresses) that differ from the connecting IP. (3) Behavioral signals: flag sessions where X-WEBAUTH-USER headers are present in requests from non-standard proxy sources or from multiple disparate IPs within short time windows. (4) Event correlation: cross-reference login via X-WEBAUTH-USER headers with absence of corresponding password authentication events. YARA-like detection: (app\.ini) AND (REVERSE_PROXY_TRUSTED_PROXIES.*=.*\*) AND (ENABLE_REVERSE_PROXY_AUTHENTICATION.*=.*true).
Mitigation Steps
Immediate actions: (1) Upgrade: patch to Gitea Docker images > 1.26.2 (when released). (2) Override defaults: administrators deploying Gitea Docker images should explicitly set REVERSE_PROXY_TRUSTED_PROXIES to the correct loopback CIDR ranges via environment variable GITEA__security__REVERSE_PROXY_TRUSTED_PROXIES=127.0.0.0/8,::1/128 at container startup. (3) Disable if unnecessary: if reverse proxy authentication is not in use, set ENABLE_REVERSE_PROXY_AUTHENTICATION=false. (4) Network isolation: restrict network access to the Gitea container to trusted reverse-proxy servers only via firewall rules or network policies. (5) Disable header parsing: if available in configuration, disable X-WEBAUTH-USER header parsing until patched. For maintainers: update the Docker template app.ini files to match the documented safe default and add validation warnings if the trusted proxies setting is overly permissive.
Risk Assessment
This vulnerability poses critical risk in production environments because: (1) Exploitation is trivial and requires no special skills or tools; any internal attacker or lateral-movement threat actor can exploit it. (2) Impact is maximum: successful exploitation grants impersonation of any user, including administrators, enabling credential theft, lateral movement, code injection into repositories, and pipeline manipulation. (3) Detectability is low: unless organizations have detailed HTTP header logging and behavioral monitoring, exploitation may go unnoticed. (4) Likelihood is moderate-to-high: Gitea is widely deployed in DevOps and enterprise environments; Docker usage is prevalent; many organizations may not have explicitly overridden defaults. (5) Threat actor interest is high: supply-chain attacks, insider threats, and network-adjacent attackers would prioritize this. Blast radius: affects all Gitea Docker image users who enabled reverse proxy authentication without manually correcting the trusted proxies setting—potentially hundreds or thousands of deployments globally.
Sources