Skip to content

Gitea Docker CVE-2026-20896 probing

Summary

CVE-2026-20896 is a critical authentication-bypass issue in official Gitea Docker images. The Docker image template hard-coded REVERSE_PROXY_TRUSTED_PROXIES = *; when reverse-proxy authentication was enabled, any source that could reach the Gitea container HTTP port directly could supply X-WEBAUTH-USER and impersonate a known or guessable user.

The Hacker News reported on July 6, 2026 that Sysdig observed the first in-the-wild probing 13 days after public disclosure. Sysdig characterized the activity as initial investigation rather than a completed intrusion at report time, with early traffic from 159.26.98[.]241 over ProtonVPN.

Tags

Why this matters

  • Gitea commonly stores source code, release automation, deploy keys, CI tokens, webhooks, package artifacts, and project secrets. A Gitea admin-session bypass can become a software-supply-chain compromise path.
  • The vulnerable state appears only when reverse-proxy authentication is enabled and the container port is reachable outside the intended authenticating proxy, making exposure easy to miss in Docker, Kubernetes, and internal-platform deployments.
  • The risky default (*) defeats the allow-list boundary: the safe documented value trusts only loopback ranges such as 127.0.0.0/8 and ::1/128.
  • Sysdig's telemetry indicates internet actors are already testing the condition soon after disclosure; defenders should treat reachable vulnerable containers as potentially probed even if exploitation has not progressed.

Public vulnerability detail

  • Affected product: official Gitea Docker images.
  • Affected versions: Docker image versions before and including 1.26.2, per Gitea reporting summarized by The Hacker News.
  • Fixed version: 1.26.3; the wildcard was removed and reverse-proxy authentication was made opt-in.
  • Vulnerability class: reverse-proxy authentication trust-boundary failure / authentication bypass.
  • Trigger condition: ENABLE_REVERSE_PROXY_AUTHENTICATION is enabled while REVERSE_PROXY_TRUSTED_PROXIES remains effectively wildcarded, and an attacker can reach the Gitea HTTP port directly rather than only through the trusted reverse proxy.
  • Impact: an unauthenticated client can send X-WEBAUTH-USER to authenticate as an existing known or guessable user; with auto-registration enabled, targeted names such as admin or gitea_admin can create administrative impact.
  • Exposure context: Sysdig cited roughly 6,200 internet-facing Gitea instances, though only the vulnerable configuration is exploitable.
  • Observed probing: Sysdig saw initial activity 13 days after public disclosure; reported source IP 159.26.98[.]241 was associated with ProtonVPN and had not progressed beyond early investigation at report time.

Defender heuristics

  1. Inventory Gitea Docker deployments, including internal developer platforms, Kubernetes services, Docker Compose stacks, lab systems, and internet-facing instances.
  2. Upgrade official Gitea Docker images to 1.26.3 or later. Rebuild and redeploy pinned images rather than only updating configuration in a running container.
  3. Review app.ini, environment variables, Helm/Compose manifests, and generated container config for ENABLE_REVERSE_PROXY_AUTHENTICATION, REVERSE_PROXY_AUTHENTICATION_USER, and REVERSE_PROXY_TRUSTED_PROXIES.
  4. Ensure only the intended authenticating proxy can reach the Gitea HTTP listener. Block direct access to the container/service port from the internet, user subnets, CI runners, and adjacent containers unless explicitly required.
  5. Replace wildcard trusted-proxy settings with a minimal list of proxy IP ranges; prefer loopback-only when the proxy and Gitea run in the same network namespace or host boundary.
  6. Hunt HTTP access logs, reverse-proxy logs, and container logs for direct requests containing X-WEBAUTH-USER, especially where the source is not a trusted proxy.
  7. Review authentication and audit logs for unexpected logins as admin, gitea_admin, maintainers, automation users, or newly created accounts following public disclosure.
  8. If suspicious access is found, rotate Gitea session secrets, deploy keys, personal access tokens, OAuth app secrets, webhook secrets, package-registry tokens, and downstream CI/CD credentials reachable from repositories.
  9. Review repository, branch-protection, webhook, release, action/runner, and package-registry changes during the exposure window for persistence or source-repository poisoning.

Sources

  • The Hacker News: https://thehackernews.com/2026/07/threat-actors-probe-gitea-docker-flaw.html
  • Gitea security advisory: https://github.com/go-gitea/gitea/security/advisories/GHSA-mgj6-v23v-2m5g
  • NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-20896