Gitea CVE-2026-20896: Docker image trusts X-WEBAUTH-USER from anywhere

CVE-2026-20896 — "Gitea Docker image trusts spoofable reverse-proxy headers by default" — was published by Gitea's CNA on July 3, 2026 and last updated by CISA's Vulnrichment program on July 7. CVSS v3.1 is 9.8 (Critical), vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. The bug is specifically in the gitea/gitea Docker image, not the tarball or the from-source build. Every image tag 1.26.2 and earlier is vulnerable. Fix is Gitea 1.26.3, but the project's own release notes tell operators to skip that build and go straight to 1.26.4 because 1.26.3 shipped a regression that breaks repository code pages.

What the bug does

Gitea supports reverse-proxy authentication: an upstream proxy authenticates the user and passes the identity to Gitea in the X-WEBAUTH-USER HTTP header. So the design decision is which upstreams Gitea is willing to trust to set that header. The documented default for REVERSE_PROXY_TRUSTED_PROXIES is 127.0.0.0/8,::1/128 — loopback only.

The Docker image ships a different default. In the container templates at docker/root/etc/templates/app.ini:55 and docker/rootless/etc/templates/app.ini:52, REVERSE_PROXY_TRUSTED_PROXIES is set to *. Every source IP is a trusted proxy. When reverse-proxy authentication is enabled, an unauthenticated caller from anywhere on the network can send X-WEBAUTH-USER: admin (or any other account name) and get that user's session. The advisory classifies the defect as CWE-284, Improper Access Control.

Credit goes to Joshua Martinelle (Tenable) and rz1027 per the CVE record.

Affected versions

• gitea/gitea Docker image ≤ 1.26.2 (both the root and rootless variants).

The from-source binary and the release tarball ship the documented loopback-only default and are not in scope. The bug is that the container template overrides that default. If your reverse-proxy authentication is enabled on any Docker deployment predating 1.26.3, you are exposed.

The fix landed in PR #38151, which drops the wildcard from the container templates so the image inherits the documented default. Gitea's own 1.26.3/1.26.4 release blog post reiterates the guidance to skip 1.26.3.

Exploitation status

CISA's ADP Vulnrichment stamp on July 6 records Exploitation: poc, Automatable: yes, Technical Impact: total. That's the state as of publication: a public proof-of-concept exists, the flaw is scriptable, and success gives an attacker full access to the impersonated account — including administrative accounts. Exploitation: poc is deliberately not active; CISA has not yet published in-the-wild attribution for this CVE, and it is not on the KEV catalog.

The exploit primitive is a single header on a single request. There is no chain, no encoding step, no authentication prerequisite. Any internet-reachable Gitea Docker instance with reverse-proxy auth enabled can be commandeered by a curl -H 'X-WEBAUTH-USER: admin' from arbitrary source IPs.

No IOCs, YARA rules, or Sigma rules have been published by the Gitea project as of this writing.

Action checklist

1. Upgrade to Gitea 1.26.4 on every Docker deployment. Skip 1.26.3. The Gitea release notes explicitly steer operators past 1.26.3 because that build breaks repository code pages with context deadline exceeded errors — new, unrelated to the CVE, but bad enough to force a re-upgrade if you land there.
2. If you can't upgrade immediately, override the wildcard. In your Gitea configuration, set REVERSE_PROXY_TRUSTED_PROXIES to the exact IP or CIDR of your legitimate reverse proxy. Restart the container. This restores the documented default posture without waiting for the image pin.
3. Confirm whether reverse-proxy auth is on. If ENABLE_REVERSE_PROXY_AUTHENTICATION is false in your app.ini, the header is ignored and this CVE does not apply — but audit rather than assume; check the running config, not the last one someone pushed to git.
4. Grep proxy and app logs for X-WEBAUTH-USER from unexpected sources. Any request bearing that header whose source address is not your legitimate reverse proxy is either a mistake to fix or an exploitation attempt to investigate.
5. Rotate credentials for administrative Gitea accounts on any instance that was internet-reachable with reverse-proxy auth on before the upgrade — SSH keys, personal access tokens, OAuth application secrets, and any deploy tokens the accounts controlled.

Context

Container-image defaults that diverge from the project's documented defaults are a recurring source of CVEs — the vendor writes the safe rule in the docs, the image maintainer writes the convenient rule in the template, and the two only converge after a critical CVE lands. Gitea's own CVE record cites the documentation's 127.0.0.0/8,::1/128 as the baseline the image was supposed to inherit, and the fix is a one-line template edit. If your organization ships container images that pre-configure any authentication-adjacent knob — trusted proxy lists, allowed hosts, CORS origins, cookie flags — this CVE is the reminder to diff the image's shipped defaults against the upstream docs on every release.