CVE-2026-20896, Gitea (Docker): trust-all reverse-proxy default lets an unauthenticated attacker impersonate any user via X-WEBAUTH-USER
Defender actions
- Patch self-hosted Gitea to 1.26.4 and fix the reverse-proxy trust scope now if you run the Docker image, set
REVERSE_PROXY_TRUSTED_PROXIESto your exact proxy IP/CIDR, or disableENABLE_REVERSE_PROXY_AUTHENTICATIONif you don't use header-auth. CVE-2026-20896 is an unauthenticated admin-takeover (CVSS 9.8). - Treat internet-reachable Gitea Docker instances as urgent: upgrade to ≥ 1.26.4 now, and set REVERSE_PROXY_TRUSTED_PROXIES to the exact proxy IP/CIDR (never the wildcard) or disable ENABLE_REVERSE_PROXY_AUTHENTICATION if header-auth is unused.
- Hunt Gitea sign-in/audit logs for X-WEBAUTH-USER-authenticated admin sessions whose source IP is not the configured trusted proxy; by construction any such hit is a spoofed header, and it is the discriminator that separates exploitation from legitimate proxy auth.
Analysis
Gitea 1.26.3 (2026-06-20) and 1.26.4 (2026-06-21) fix a cluster of four flaws; the critical one is CVE-2026-20896 (CVSS 9.8). The official Gitea Docker image shipped with REVERSE_PROXY_TRUSTED_PROXIES defaulting to the wildcard *, meaning Gitea trusts the reverse-proxy authentication header from any source. Any attacker who can reach the container's HTTP port can therefore send an X-WEBAUTH-USER header naming an arbitrary user (including an administrator) and be authenticated as that user with no credentials (Gitea, 2026-06-21; GitHub Security Advisory GHSA-f75j-4cw6-rmx4, 2026-06-21). Bare-metal deployments with an explicit trusted-proxy CIDR are unaffected unless they also set the wildcard. The same release also patches CVE-2026-27775 (protected-branch enforcement race in single-push batch operations), CVE-2026-20779 (CVSS 7.1, TOTP 2FA bypass via a web-flow TOCTOU race and stateless X-Gitea-OTP replay inside the OTP validity window) and CVE-2026-22874 (SSRF in the webhook / repo-migration subsystems). Germany's BSI issued WID-SEC-2026-2027 on 2026-06-22 rating the set "hoch" (BSI WID, 2026-06-22). No in-the-wild exploitation reported yet; included on the pre-auth-critical-on-widely-deployed-software gate. Gitea is the dominant self-hosted GitHub alternative across DACH/EU public-sector DevOps and sovereign-cloud environments, so an internet-reachable or loosely-segmented Docker instance is an immediate admin-takeover risk (T1190 Exploit Public-Facing Application, T1078.001 Default Accounts). Mitigations: set REVERSE_PROXY_TRUSTED_PROXIES to the exact reverse-proxy IP/CIDR, or disable ENABLE_REVERSE_PROXY_AUTHENTICATION entirely if header-auth is not used; upgrade to 1.26.4. Hunt for admin logins sourced from the reverse-proxy IP with no corresponding password-auth audit entry, and webhook calls to RFC-1918 addresses.
Cited evidence
the Docker image defaulted REVERSE_PROXY_TRUSTED_PROXIES to wildcard '*' ... anyone who can reach the container's HTTP port can authenticate as any Gitea user by supplying an X-WEBAUTH-USER header
WID-SEC-2026-2027 (Gitea: Mehrere Schwachstellen ermöglichen nicht autorisierten Zugriff und weitere Angriffe) Risiko: hoch
Current exploitation status: Actively Exploited, Proof of Concept Available
Successful exploitation allows unauthenticated attackers to gain full administrative control of Gitea instances via a single custom HTTP header.
So far, the activities have been related to initial investigation by the threat actor,
Updates1
Switzerland's NCSC added CVE-2026-20896 to its Cyber Security Hub on 2026-07-10 (08:55 UTC) and set its current exploitation status to "Actively Exploited, Proof of Concept Available", reiterating that "[s]uccessful exploitation allows unauthenticated attackers to gain full administrative control of Gitea instances via a single custom HTTP header" (NCSC-CH, 2026-07-10). This is the first national-CERT escalation of the flaw's status since the June disclosure of the Docker image's trust-all REVERSE_PROXY_TRUSTED_PROXIES default (mechanics and patch unchanged from the original entry).
The escalation warrants a caveat rather than a panic. The only public exploitation reporting traces to Sysdig telemetry surfaced on 2026-07-06, and the two outlets that carried it diverge. The Hacker News quotes Sysdig's Michael Clark saying the single probe from a ProtonVPN-associated IP had "not so far progressed to any exploitation or attack progress" and characterises the activity as initial investigation by the threat actor rather than compromise (The Hacker News, 2026-07-06). SecurityWeek's coverage of the same Sysdig telemetry frames it as active exploitation and omits that caveat (SecurityWeek, 2026-07-07), so the "actively exploited" characterisation is itself contested across the very reporting NCSC-CH cites. NCSC-CH's advisory does not resolve the gap with its own data, so the defensible read is "scanning confirmed, compromise unconfirmed", which changes nothing about the remediation priority: a public PoC exists for a pre-auth admin-takeover on software Sysdig counts at roughly 6,200 internet-facing instances, and self-hosted Gitea is common across DACH/EU public-sector and academic DevOps.
Sources6
Revision history
- Published 2026-06-23-165387f6
- Update 2026-07-10T1228Z-intel
Switzerland's NCSC published an advisory on 2026-07-10 raising the exploitation status of the Gitea Docker-image reverse-proxy auth bypass (CVE-2026-20896, CVSS 9.8) to "Actively Exploited, Proof of Concept Available". The underlying flaw (the official Docker image trusting a spoofable X-WEBAUTH-USER header from any source IP for unauthenticated admin impersonation) was covered on 2026-06-23; the in-window delta is the national-CERT exploitation-status escalation. Public telemetry to date (Sysdig, via SecurityWeek/The Hacker News) still shows only reconnaissance-stage probing, so treat NCSC-CH's "actively exploited" label as a national-authority assessment and prioritise patching internet-reachable Docker instances now.
Changed: actions affected_products cves evidence regions sources tags techniques body
AI-generated · no human review · this permalink is the shareable record for the finding · verify operationally critical claims against the linked primary source.