A Gitea Docker vulnerability disclosed last month is now drawing real attacker interest, and it is easy to see why. CVE-2026-20896, rated 9.8 out of 10 on the CVSS scale, let anyone who could reach a Gitea container’s HTTP port impersonate any user, including an administrator, by sending one forged HTTP header. No exploit chain, no credentials, no second step.
What the Gitea Docker vulnerability breaks
The bug does not live in Gitea’s application code. It lives in a default setting inside the official Docker image. Gitea supports reverse-proxy authentication, where a proxy in front of the app vouches for a user’s identity through the X-WEBAUTH-USER header. That only works safely if Gitea trusts the header solely when it arrives from the proxy itself.
The Docker image’s app.ini template set REVERSE_PROXY_TRUSTED_PROXIES to a wildcard, *, instead of the safe default of loopback addresses only. Every request on the network path to the container was treated as if it came from a trusted proxy. Anyone who could set an X-WEBAUTH-USER header could claim to be any username they liked, admin included, according to the GitHub security advisory.
The flaw only bites when reverse-proxy authentication is switched on and the container’s HTTP port is reachable without going through the intended proxy. That happens more often than administrators expect. A container can end up exposed on a shared network, behind a misconfigured load balancer, or sharing a Docker network with other services and no strict firewall rules between them.
Sysdig catches attackers probing the door
Gitea shipped the fix in version 1.26.3 on 20 June, days after a researcher credited as rz1027 reported it. Threat intelligence firm Sysdig says the quiet period did not last long. Researcher Michael Clark found the first in-the-wild exploitation attempt 13 days after the patch went out, originating from a ProtonVPN exit address, 159.26.98[.]241.
“No password. No token. One header,” Clark wrote, summing up why the bug is so attractive to opportunistic scanners. The activity Sysdig observed looked like reconnaissance rather than a completed takeover. Still, the Gitea Docker vulnerability was on scanning lists barely two weeks after disclosure, well within the window plenty of self-hosted instances take to patch.
Why an exposed Gitea instance matters
Gitea holds source code, issue trackers, CI configuration and, often, secrets that developers forgot were ever committed. Whoever gets to impersonate an admin account can read private repositories, pull API keys and deployment credentials out of history, and push commits under a trusted identity. That is a heavier prize than most credential-stuffing targets, which is why researchers are treating the probing activity as an early warning rather than background noise.
Roughly 6,200 internet-facing Gitea instances turn up on Shodan, a figure that includes patched installs and non-Docker deployments alongside anything still running the vulnerable default. Nobody has published a breakdown of how many are still on 1.26.2 or earlier, and that uncertainty is exactly what makes patching now the safer bet. Self-hosted Git servers are popular precisely because they keep code off a third party’s infrastructure. That only pays off if the server itself is locked down as carefully as the repositories it holds.
What to fix, and what else shipped alongside it
Version 1.26.3, and a same-week follow-up in 1.26.4, closed the Gitea Docker vulnerability along with nine other issues in one release, according to Gitea’s own release notes. The batch included an incomplete SSRF protection (CVE-2026-22874), a branch-permission escalation bug (CVE-2026-27775), a fork-synchronisation flaw (CVE-2026-24451), and a TOTP passcode replay issue (CVE-2026-20779). It also covered weak LFS object access control (CVE-2026-28740), an over-broad RSS feed token scope (CVE-2026-27761), an organisation label leak (CVE-2026-25038), an SSH-based LFS authentication bypass, and a CODEOWNERS regular-expression denial of service. Version 1.26.4 added a further fix so disabled users cannot be silently reactivated through an OAuth2 callback.
Anyone running Gitea in Docker and still on 1.26.2 or earlier carries the full Gitea Docker vulnerability along with the other nine issues, not just the header bug. The practical steps are short. Update to 1.26.3 or 1.26.4. If reverse-proxy authentication is enabled, set REVERSE_PROXY_TRUSTED_PROXIES to the actual address of the proxy rather than leaving it wide open. Then check access logs for admin sessions nobody on the team can account for, since impersonation through this bug leaves little else behind.