Gitea Authentication Bypass Exposes Private Repositories Through Default Docker Reverse Proxy Setting

A critical authentication bypass vulnerability in Gitea, tracked as CVE-2026-20896 with a CVSS score of 9.8, allows attackers to gain administrative access and read private repositories by sending a single HTTP header. The root cause lies in the official Docker image defaulting the REVERSE_PROXY_TRUSTED_PROXIES setting to a wildcard, trusting the X-WEBAUTH-USER header from any source when reverse-proxy authentication is enabled. The researcher reproduced the full attack on a live vulnerable instance, demonstrating how an unauthenticated request could retrieve secret files such as .env containing database passwords and cloud keys. Multiple related access-control flaws were also disclosed in the same year, including CVE-2026-27771 affecting the container registry, CVE-2026-22874 in webhooks, and CVE-2026-28740 in LFS handling. The recommended fix involves explicitly setting trusted proxy IPs or disabling reverse-proxy authentication entirely and upgrading to version 1.26.4 or later. The issue highlights recurring problems with overly permissive defaults in self-hosted DevOps tools.

HabrTranslated from Russian

Read at source

A critical authentication bypass vulnerability has been demonstrated in Gitea, allowing attackers to impersonate administrators and access private repositories simply by sending one HTTP header. The flaw, assigned CVE-2026-20896 and rated 9.8 on the CVSS scale, stems from a dangerous default in the official Docker image that trusts the X-WEBAUTH-USER header from any IP address.

Root Cause and Attack Flow

Gitea supports authentication via a reverse proxy for single sign-on scenarios. When enabled, the proxy authenticates the user and passes the username in the X-WEBAUTH-USER header. The application trusts this header only from addresses listed in the REVERSE_PROXY_TRUSTED_PROXIES configuration option. In the official Docker image the default value was set to a wildcard (“*”), meaning any source could supply the header.

An attacker could therefore send a request such as:

  • curl -H 'X-WEBAUTH-USER: admin' http://target:3000/admin/secret-infra/raw/branch/main/.env

and immediately retrieve the contents of a private repository file containing production secrets.

Additional Related Vulnerabilities

The same pattern of broken access control appeared in several other Gitea components throughout 2026:

  • CVE-2026-27771 – private container images were served anonymously through the built-in OCI registry.
  • CVE-2026-22874 – an overly permissive allow-list allowed SSRF via webhooks and migrations.
  • CVE-2026-28740 – authorization bypass in LFS permitted reading objects from private repositories without proper rights.

These issues affected both Gitea and its fork Forgejo, impacting tens of thousands of internet-facing instances.

Recommended Mitigations

Administrators are advised to:

  • Upgrade to Gitea 1.26.4 or newer (avoid 1.26.3 due to a regression in the SSRF fix).
  • Explicitly configure REVERSE_PROXY_TRUSTED_PROXIES to the IP or CIDR of the actual reverse proxy.
  • Disable reverse-proxy authentication if it is not required.
  • Place Gitea behind a reverse proxy or WAF and monitor logs for 200 responses to administrative paths from unexpected source IPs.

The researcher emphasizes that the incident is not an isolated coding error but a systemic problem caused by overly permissive defaults in official container images.

Meridian digestThe week's most consequential security stories, distilled into one briefing.See the digest

More in Vulnerabilities & Exploits

Telegram for Android Patches Voice Call Vulnerability Enabling Code Execution
Yandex Patches Millions of Stations After eMudhra Certificate Keys Compromised
Cisco ASA and FTD Face DoS Vulnerability in SSL VPN Already Exploited in the Wild