Gitea Docker images: CVE-2026-20896 — one HTTP header is enough for admin access, now actively scanned

TL;DR — 90 seconds

Affected?

Gitea instances built from the official Docker image (docker/root and docker/rootless), version 1.26.2 and earlier, with ENABLE_REVERSE_PROXY_AUTHENTICATION = true. Binary installs following app.example.ini are not affected.

Risk?

Unauthenticated privilege escalation to admin via X-WEBAUTH-USER header spoofing. CVSS 3.1 9.8 (critical) — network, no auth, no interaction required.

Immediate action?

Upgrade to Gitea 1.26.4 (press reports say 1.26.3 has a regression — target 1.26.4 directly), or, if an update isn't immediately possible, manually set REVERSE_PROXY_TRUSTED_PROXIES to 127.0.0.0/8,::1/128.

Recommendation?

Patch today, not this week: actively scanned since 7 July 2026 (Sysdig), ~6,200 instances potentially reachable per a Shodan query (the actual number of vulnerable instances is unconfirmed).

Criticality?

critical (hero badge) — full unauthenticated admin takeover given direct access to the container port.

What is the problem?

Gitea supports reverse-proxy authentication: an upstream proxy handles the actual login and passes the verified identity to the application via an HTTP header (X-WEBAUTH-USER). For this to be safe, Gitea must only trust that header when the request genuinely comes from the proxy — controlled via REVERSE_PROXY_TRUSTED_PROXIES. The documented safe default is loopback-only (127.0.0.0/8,::1/128).

That exact default is set wrong in the official Docker image templates: docker/root/etc/templates/app.ini (line 55) and the corresponding rootless variant (line 52) hardcode REVERSE_PROXY_TRUSTED_PROXIES = * instead — a wildcard that treats every source address as trusted. With ENABLE_REVERSE_PROXY_AUTHENTICATION enabled (common in reverse-proxied deployments), a self-set X-WEBAUTH-USER header from any source is enough to impersonate the named user — admin accounts included. Security researcher Ali Mustafa, who reported the flaw, put it plainly: any process that can reach the container's HTTP port directly can impersonate any user, regardless of whether the instance is publicly reachable or “only” internal.

Important context: binary installs following the official app.example.ini are not affected by this finding — the problem is confined to the Docker image templates.

Who is affected?

A Shodan query shows roughly 6,200 Gitea instances that are generally internet-reachable; how many of those actually run the vulnerable Docker image and configuration is not established by that number — only the rough attack surface.

Impact

Successful exploitation means full identity takeover, not just read access: spoofing an admin via the header grants access to all repositories including private ones, visibility into CI/CD secrets stored in repository or organization variables, the ability to push commits to protected branches, tamper with CI pipelines, and create or delete user accounts. Because self-hosted git servers like Gitea typically bundle both source code and deployment secrets, this finding is a multiplier for downstream supply-chain risk: a compromised Gitea instance is a plausible starting point for compromised downstream artifacts.

Exploitation requires no authentication and no user interaction — only network access to the container's HTTP port. That's the core of the CVSS 3.1 score of 9.8.

Mitigation / immediate steps

Note: the following steps are my operational take based on GHSA-f75j-4cw6-rmx4 and the cited reporting — not a vendor-certified guide. Reconcile concrete version levels against the Gitea advisory.

Operational decision block

• Act now if … you run the official Docker image with ENABLE_REVERSE_PROXY_AUTHENTICATION = true and haven't explicitly set REVERSE_PROXY_TRUSTED_PROXIES.
• Check with priority if … you're unsure whether your image build follows the vulnerable template.
• Monitor only if … you run a binary install following app.example.ini with trusted proxies correctly set.

Step 1 — upgrade to 1.26.4

# check current version
docker exec <gitea-container> gitea --version
# pull the patched image (1.26.4 — 1.26.3 reportedly has a regression)
docker pull gitea/gitea:1.26.4
docker compose up -d gitea

Step 2 — until patched, restrict trusted proxies manually

# in app.ini (volume mount or docker exec into the container):
[security]
REVERSE_PROXY_TRUSTED_PROXIES = 127.0.0.0/8,::1/128
# restart
docker restart <gitea-container>

Step 3 — harden the network

# don't expose the container's HTTP port directly — only the reverse proxy should reach it
# check docker-compose.yml for 0.0.0.0 bindings that bypass the proxy
# on Kubernetes: NetworkPolicy restricting the pod's port to ingress/proxy only

Step 4 — if not needed, disable reverse-proxy auth

[service]
ENABLE_REVERSE_PROXY_AUTHENTICATION = false

Detection / verification

Check points derived from the advisory and common Docker/log practice.

Version & config check

docker exec <gitea-container> gitea --version
docker exec <gitea-container> grep -A3 "\[security\]" /data/gitea/conf/app.ini | grep -i trusted_proxies
docker exec <gitea-container> grep -i enable_reverse_proxy /data/gitea/conf/app.ini

Check logs for header spoofing

# X-WEBAUTH-USER from sources outside the expected proxy IP in the access log?
grep -i "x-webauth-user" /path/to/reverse-proxy/access.log | awk '{print $1}' | sort -u

Check the admin list for unknown accounts

curl -s -H "Authorization: token <admin-token>" \
  gitea.example.com/api/v1/admin/users | jq '.[] | select(.is_admin==true) | .login'

Runtime indicators

- new/unknown admin accounts
- unexpected commits on protected branches
- CI/CD pipeline changes outside known deploy windows
- X-WEBAUTH-USER headers on requests not originating from the configured proxy

Operator guidance

Mid-market

Patch to 1.26.4 this week — Gitea instances typically bundle source code and CI secrets, which turns this finding into a lever for downstream incidents. Check in parallel whether REVERSE_PROXY_TRUSTED_PROXIES was ever explicitly set; if not, your instance has likely been exposed since the Docker image was built.

Enterprise

Additionally: audit container network exposure — is the HTTP port reachable beyond the intended proxy hop? Internal segmentation matters here since the finding doesn't require public exposure. Reconcile SBOM/inventory for which internal systems have direct network access to Gitea containers.

Kubernetes

Check the NetworkPolicy restricting access to the Gitea pod's HTTP port to ingress/proxy only; audit Service type (avoid NodePort/LoadBalancer exposing the raw port); update the image pin to 1.26.4 in Helm values/manifests.

Decision block

Act today if: Docker image + reverse-proxy auth active + REVERSE_PROXY_TRUSTED_PROXIES unchecked. Monitor if: binary install with the documented safe default.

Conclusion

CVE-2026-20896 is a textbook case of a single wrong default in a distribution template — not the application code itself — becoming unauthenticated admin takeover. The fix is straightforward (an update or one line of config), but exploitation is trivial and has been actively observed since 7 July 2026. Anyone running Gitea from the official Docker image with reverse-proxy auth enabled should check REVERSE_PROXY_TRUSTED_PROXIES today — regardless of whether the instance is publicly reachable.

Sources

• Gitea Security Advisory GHSA-f75j-4cw6-rmx4 (go-gitea/gitea; authoritative fix version 1.26.3)
• The Hacker News — Threat Actors Probe Gitea Docker Flaw CVE-2026-20896 13 Days After Disclosure (6 Jul 2026)
• Tech Times — Gitea Docker Flaw Now Actively Probed (12 Jul 2026; notes a regression in 1.26.3, recommends 1.26.4)
• Security Affairs — Critical Gitea Docker Bug Under Active Exploitation (7 Jul 2026; ~6,200 instances per Shodan)