Gitea Docker Auth Bypass Under Active Attack: CVE-2026-20896 Explained

A default setting shipped in an official Docker image has turned into one of the more straightforward authentication bypasses seen this year, and it is already being probed in the wild.

The flaw, tracked as CVE-2026-20896 and carrying a CVSS score of 9.8, affects Gitea's official Docker images through version 1.26.2. Gitea is a self-hosted, open-source Git platform, comparable to running your own GitHub or GitLab instance, widely used by development teams that want full control over their source code and CI/CD pipelines rather than relying on a third-party host.

The root cause sits in a configuration file. Gitea's Docker image ships with an app.ini template that hardcodes the trusted proxy setting to a wildcard. Many organisations place Gitea behind a reverse proxy that handles login and passes the authenticated username to Gitea through an HTTP header. That setup only works safely if Gitea trusts that header solely when it comes from the proxy itself. Because the wildcard setting instead trusts that header from any source, anyone who can reach the Gitea container's HTTP port directly, bypassing the intended proxy, can send that same header themselves and be authenticated as any user whose username they know or can guess. Administrator accounts are the obvious target, and if the instance has auto-registration enabled, an attacker does not even need an existing account to impersonate. No password, no token, no session cookie is required.

Security researcher Ali Mustafa is credited with discovering and reporting the flaw. Gitea fixed it in versions 1.26.3 and 1.26.4, released in late June, by removing the wildcard default entirely and making the underlying reverse-proxy authentication feature opt-in rather than automatic.

The concerning part is how quickly this moved from disclosure to attempted exploitation. Cloud security firm Sysdig reports that its sensors caught the first in-the-wild probing attempt just thirteen days after the public advisory, originating from infrastructure associated with a commercial VPN service. Sysdig's threat research team estimates roughly 6,200 Gitea instances are directly reachable from the internet, though it is not clear how many remain on a vulnerable version. Given how quickly reconnaissance activity followed disclosure, unpatched public-facing instances should be treated as exposed rather than merely theoretical risk.

The impact of a successful compromise is significant precisely because of what Gitea holds. An attacker with admin-level access can read and modify private repositories, which routinely include the source code an organisation ships, along with the secrets developers occasionally commit by accident such as API keys, database credentials, and deployment tokens. CI/CD configuration and deploy keys stored in those repositories are equally exposed, giving an attacker a path from a single misconfigured Git server into the wider development and deployment pipeline.

The remediation is direct. Organisations running Gitea via Docker should upgrade to version 1.26.3 or later immediately. Where an upgrade cannot happen right away, the interim fix is to edit the app.ini configuration and replace the wildcard trusted-proxy setting with the specific IP address of the actual reverse proxy, rather than leaving it open to any source. Teams should also check whether reverse-proxy authentication is genuinely needed at all; if it is not in active use, disabling it removes the exposure outright.

Beyond the immediate patch, this is worth logging as an example of a broader and recurring weak point. Weak identity and access management, trusting a credential signal without verifying where it actually came from, remains one of the most common gaps regulators flag in enterprise security reviews, and it is exactly the kind of default configuration issue that a source-code exposure incident earlier this year also traced back to. Any organisation running self-hosted developer tooling should treat default configuration values as something to verify, not assume, particularly where authentication is involved.