Threat actors began actively probing internet-facing Gitea Docker instances for CVE-2026-20896 roughly thirteen days after the flaw’s public disclosure, with initial reconnaissance traced to a ProtonVPN exit node. The vulnerability carries a CVSS score of 9.8 and lets an attacker bypass authentication entirely by sending a single HTTP header containing a valid username.
The root cause is a default configuration flaw: Gitea Docker images before version 1.26.3 shipped with REVERSE_PROXY_TRUSTED_PROXIES set to a wildcard, meaning Gitea trusted the reverse-proxy authentication header regardless of where the connecting request actually originated. Any HTTP client that could reach the instance could assert an administrative identity outright, gaining access to repositories and stored secrets.
This is a textbook case of a secure-by-default assumption failing in practice — reverse-proxy header trust is meant to be scoped to a known, trusted proxy, and an overly permissive default inverted that model for every affected deployment. The thirteen-day gap between disclosure and active exploitation is also a reminder that “already patched, low urgency” windows close faster than they used to.
Gitea 1.26.3 and 1.26.4 fix the issue by removing the wildcard default and making reverse-proxy authentication opt-in. If you run Gitea via Docker, upgrade immediately, and if you can’t patch right away, explicitly set the trusted proxy list rather than relying on defaults. Review access logs for authentication events carrying unexpected proxy headers as a sign of attempted exploitation.