Gitea’s Docker Image Trusted Every Proxy on Earth — and Hackers Took Advantage

Category: Self-Hosting / Security
Tags: gitea, docker, security, CVE, self-hosting, authentication bypass

If you self-host Git with Gitea in Docker, you might want to check your version right now. A critical authentication bypass vulnerability — CVE-2026-20896, rated 9.8 out of 10 on the CVSS scale — let anyone who could reach your Gitea container’s HTTP port impersonate any user, including the administrator. No password. No token. Just one forged HTTP header.

The fix shipped on June 20 in version 1.26.3, but here’s the part that keeps self-hosters up at night: security researchers at Sysdig confirmed the first in-the-wild exploitation attempts just 13 days after the patch was released.

The Bug: A Wildcard That Trusted Everyone

The vulnerability doesn’t live in Gitea’s application code. It lives in a single line inside the official Docker image’s app.ini configuration template.

Gitea supports reverse-proxy authentication, where a proxy sitting in front of the application vouches for a user’s identity through the X-WEBAUTH-USER header. This is how you integrate Gitea with existing auth systems — your proxy authenticates the user, then tells Gitea “this request is from user X.”

The security model only works if Gitea trusts that header solely when it arrives from the proxy itself. You configure REVERSE_PROXY_TRUSTED_PROXIES to list the specific IP addresses of your trusted reverse proxy.

Except the official Docker image shipped with:

REVERSE_PROXY_TRUSTED_PROXIES = *

A wildcard. Every request on every network path to the container was treated as if it came from a trusted proxy. Anyone who could send an HTTP request with an X-WEBAUTH-USER header could claim to be any username they liked. Admin included.

As Michael Clark, leading security researcher at Sysdig, put it:

“Gitea’s official Docker image ships REVERSE_PROXY_TRUSTED_PROXIES=*. With reverse-proxy authentication enabled, Gitea then trusts the X-WEBAUTH-USER header from any source IP so an unauthenticated internet client becomes whoever it claims to be. No password. No token. One header.”

How It Plays Out in the Real World

The flaw only bites when two conditions are met:

1. Reverse-proxy authentication is enabled — which is common in production deployments integrating with existing identity providers
2. The container’s HTTP port is reachable — without going through the intended proxy

That second condition happens more often than administrators expect. A container can end up exposed on a shared Docker network, behind a misconfigured load balancer, or visible to other services without strict firewall rules between them. If your Gitea container shares a network with another service and you have reverse-proxy auth turned on, any of those services (or a compromised one) could forge authentication headers.

For internet-exposed instances, the attack is even simpler. Send a curl request with the header, and you’re in:

curl -H "X-WEBAUTH-USER: admin" http://your-gitea-instance.com/

That’s it. No exploit chain, no credentials, no second step.

The Timeline

• Researcher rz1027 reported the vulnerability to the Gitea team
• Gitea released version 1.26.3 on June 20, 2026 with the fix
• The fix changes the Docker image default from * to loopback addresses only — the safe default it should have been all along
• July 3, 2026: Sysdig’s automated sensors detected the first in-the-wild exploitation attempt — a VPN-exit scanner that grabbed access within seconds
• July 7: The story goes public via security news outlets
• Currently, approximately 6,200 Gitea instances are exposed on the public web

Why This Matters Beyond Gitea

This isn’t just a Gitea problem — it’s a textbook example of a pattern that appears across the self-hosting ecosystem. Docker images that ship with permissive defaults, configuration templates that prioritise convenience over security, and features that work perfectly when everything is set up correctly but fall apart the moment assumptions break down.

The wildcard trust configuration is the Docker-image equivalent of shipping a house with the front door unlocked and a note saying “please only open this from the hallway.” The code doesn’t distinguish between a header from your Nginx reverse proxy and a header from a random IP on the internet.

It also highlights how quickly automated scanners pick up newly disclosed vulnerabilities. Thirteen days from patch to exploitation is fast — and that’s for a vulnerability where the fix was already available. Anyone running an unpatched version in that window was already being probed.

What to Do If You Run Gitea

1. Update to 1.26.3 or later immediately if you haven’t already
2. Check your app.ini — even if you updated, verify that REVERSE_PROXY_TRUSTED_PROXIES is set to your actual proxy IP, not *
3. Review your Docker network configuration — ensure your Gitea container isn’t unnecessarily exposed to other containers or external networks
4. Consider disabling reverse-proxy authentication entirely if you’re using built-in Gitea authentication instead

The vulnerability affects deployments using the default configuration. If you explicitly set REVERSE_PROXY_TRUSTED_PROXIES to specific IPs, you were likely never vulnerable — but the official Docker image makes the wrong choice by default, and many people never change it.

The Lesson

Shipping a wildcard trust configuration in a Docker image is an easy mistake to make and an even easier one to exploit. For self-hosters, the takeaway is familiar but worth repeating: check your defaults, especially the ones that came pre-configured in a convenience image. The internet doesn’t care about your assumptions.