Gitea CVE-2026-20896

Exploitation requires that the operator has enabled Gitea's reverse-proxy authentication feature (the ENABLE_REVERSE_PROXY_AUTHENTICATION path using headers such as X-WEBAUTH-USER) while running the official Docker image with its default REVERSE_PROXY_TRUSTED_PROXIES=* setting, AND that the attacker can send HTTP requests to the Gitea instance directly rather than being forced through the legitimate proxy. When these hold, an attacker simply supplies the reverse-proxy identity header with a chosen username to impersonate any account. Limiting factors: this is NOT exploitable against default installs that never enabled reverse-proxy header authentication; deployments that already pinned REVERSE_PROXY_TRUSTED_PROXIES to the proxy's IP/CIDR are unaffected; and if network segmentation prevents clients from reaching the container except via the trusted proxy, header spoofing is blocked at the perimeter.

The supplied CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, base 9.8) reflects the worst case: once reverse-proxy auth is enabled, a network attacker with no privileges or user interaction can impersonate any user, including admins, yielding full confidentiality, integrity and availability impact over the repositories. The critical qualifying factor NVD's vector does not encode is that exploitation is conditional on the operator having enabled reverse-proxy header authentication AND exposing Gitea such that clients can reach it directly (bypassing or alongside the proxy) - in a correctly segmented deployment where only the proxy can reach Gitea, the wildcard is far less exploitable. No EPSS score, KEV listing, or POC was provided; there is no public exploit identified at time of analysis, so despite the 9.8 rating real-world risk is concentrated on the subset of Docker deployments that turned on reverse-proxy auth without overriding the default trusted-proxy list. Treat as high priority for that configuration and low for default installs that never enabled header auth.

An organization runs the Gitea Docker image behind a reverse proxy with X-WEBAUTH-USER authentication enabled but leaves the default REVERSE_PROXY_TRUSTED_PROXIES=*. An attacker who can reach the Gitea service directly sends an HTTP request with a forged X-WEBAUTH-USER: admin header; because all source IPs are trusted, Gitea accepts the identity and grants the attacker that user's session, leading to repository and administrative takeover. No public POC has been identified, but the technique requires only a single crafted request and low skill.