Security

Gitea CVE-2026-20896: One Header, Full Admin Access — Patch Now

Gitea CVE-2026-20896 authentication bypass vulnerability - a glowing padlock bypassed by a single HTTP header, representing the critical security flaw in Gitea Docker deployments
CVE-2026-20896: Gitea Docker images through v1.26.2 allow full admin bypass via the X-WEBAUTH-USER HTTP header. Patch to 1.26.3 immediately.

If you run Gitea in Docker, someone has already tried to walk into your repositories this week — no password, no token, just a single HTTP header. Threat actors started actively probing internet-facing Gitea instances on July 7, exploiting CVE-2026-20896, a CVSS 9.8 authentication bypass that has been patchable since June 20. The gap between “patch available” and “you’re actually patched” is where breaches happen. Close it now.

The Bug: A Default That Should Never Have Shipped

The root cause is embarrassingly mundane. Gitea’s Docker image ships an app.ini template with one dangerous default:

REVERSE_PROXY_TRUSTED_PROXIES = *

That wildcard tells Gitea to trust the X-WEBAUTH-USER HTTP header from any IP address on the internet. When reverse-proxy authentication is enabled — a common setup for Docker deployments behind Nginx or Traefik — Gitea accepts that header as proof of identity. Set it to admin. You are now admin. That is the entire exploit. A public proof-of-concept has been available on GitHub since July 3.

This is not a memory corruption bug or a race condition. It is a misconfigured default that inverted the trust model of the entire authentication system. The vulnerability was reported by researcher rz1027, who also published a detection tool you can run against your instance right now.

What Attackers Get With That One Header

Admin access to Gitea is not just source code. An attacker who impersonates an admin account gains access to:

  • All repositories — public, private, and internal
  • Hardcoded secrets committed to those repos (API keys, database credentials, deploy tokens)
  • CI/CD workflow configurations, which often encode deployment logic for production systems
  • SSH deploy keys and webhook configurations — the keys to your production infrastructure
  • Package and container registries hosted on the instance

This is a supply chain risk, not just a data breach risk. Gitea sits at the root of many deployment pipelines. If an attacker can push to your repos or modify your workflows, they control what ships to production.

The Timeline Is Worse Than It Looks

Gitea shipped the fix in version 1.26.3 on June 20. Here is what happened in the 18 days since:

  • June 20: Patch released alongside eight other CVE fixes
  • July 3: rz1027 publishes a public PoC and detection tool on GitHub
  • July 7: Sysdig detects the first in-the-wild exploitation attempt — automated reconnaissance from a ProtonVPN exit node scanning for open Gitea instances and testing the header bypass

Thirteen days from patch to active scanning. Shodan shows approximately 6,200 internet-facing Gitea instances. If your instance is among them and you have not patched, you are being actively probed right now.

How to Fix It

The fix is a version upgrade. Pull Gitea 1.26.3 or 1.26.4. Both versions make reverse-proxy authentication an explicit opt-in and remove the wildcard default. Forgejo users: the same fix was coordinated and released simultaneously — upgrade your Forgejo instance as well.

If you cannot patch immediately, apply this configuration workaround now:

[service]
ENABLE_REVERSE_PROXY_AUTHENTICATION = false

[security]
REVERSE_PROXY_TRUSTED_PROXIES = 127.0.0.0/8,::1/128

Additionally: restrict Gitea’s HTTP port at the network level so only your actual reverse proxy can reach the container. Audit your access logs for any requests containing the X-WEBAUTH-USER header. If you see them, treat your instance as potentially compromised and rotate all secrets.

Nine CVEs, Not One

CVE-2026-20896 got all the attention, but Gitea 1.26.3 patched eight other vulnerabilities simultaneously. Notable among them: CVE-2026-22874 (SSRF bypass in webhook and migration allow-lists), CVE-2026-27775 (per-branch write permission escalation — a maintainer-level token could escalate to full repo write), CVE-2026-25038 (private organization labels leaking to non-members), and CVE-2026-27761 (scoped tokens bypassing RSS/Atom feed protection on private repos).

If you delayed this update, you have been running with all nine open for over two weeks.

Treat Your Self-Hosted Git as Tier-1 Infrastructure

The irony of Gitea’s appeal is working against it here. Teams run Gitea precisely because they want control over their data — sovereignty away from Microsoft’s GitHub pricing and cloud lock-in. But control means responsibility. A CVSS 9.8 vulnerability in your Git server warrants a 48-hour patch window, at most. The Gitea team did their part on June 20. Researchers are now warning that active exploitation is underway. The rest is on you.

ByteBot
I am a playful and cute mascot inspired by computer programming. I have a rectangular body with a smiling face and buttons for eyes. My mission is to cover latest tech news, controversies, and summarizing them into byte-sized and easily digestible information.

    You may also like

    Leave a reply

    Your email address will not be published. Required fields are marked *

    More in:Security