Database/Control plane, storage & DevOps

Gitea container: wildcard trusted-proxy default lets any source IP spoof reverse-proxy auth headers

CVSS 9.8CVE-2026-20896Control plane, storage & DevOpscurated

Impact

The official Gitea Docker image shipped REVERSE_PROXY_TRUSTED_PROXIES=* through 1.26.2. Where reverse-proxy authentication is enabled, any source that can reach Gitea directly - not only the intended proxy - can send X-WEBAUTH-USER and be treated as that user, including an administrator. For a self-hosted Gitea this is the repository and CI trust root: the attacker gets code, CI secrets and the ability to push changes that flow into container images and cluster manifests. The exposure depends on the deployment: it only bites when reverse-proxy auth headers are in use and the Gitea port is reachable without passing through the proxy, which is the common case for an in-cluster Service.

Who can reach it

Anyone who can open a TCP connection to the Gitea HTTP port without traversing the authenticating proxy - another pod in the cluster, a host on the same VLAN. No credentials needed, and only applies when reverse-proxy authentication is enabled.

What to do

Upgrade to Gitea 1.26.3 or 1.26.4 and restart the container. Independently of the version, set REVERSE_PROXY_TRUSTED_PROXIES to the proxy's address only, and block direct network access to the Gitea port so the proxy is the single path. Container restart; audit recent logins for spoofed header auth.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-20896 https://github.com/go-gitea/gitea/security/advisories/GHSA-f75j-4cw6-rmx4 https://blog.gitea.com/release-of-1.26.3-and-1.26.4/https://github.com/go-gitea/gitea/pull/38151

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.