Lead Analysis
Security & Risk6 min

Gitea Under Attack: Docker Image Flaw Allows Admin Access with a Single HTTP Header

Mão pairando sobre teclado com terminal mostrando linha de requisição HTTP destacada em vermelho e relatórios de dependência empilhados ao lado.

Sysdig detected the first exploitation attempt 13 days after the patch, affecting 6,200 exposed instances. The bug originates from a line in app.ini that trusts any IP.

Cloud security company Sysdig announced on Tuesday that it has detected the first real exploitation attempt of CVE-2026-20896, an authentication bypass flaw with a CVSS score of 9.8 in Gitea's Docker images. The attempt originated from a ProtonVPN address (159.26.98.241) and occurred 13 days after the project released version 1.26.3, which fixed the issue on June 20. There are approximately 6,200 internet-facing instances of Gitea, a number that combines self-hosted servers by engineering teams and internal implementations by companies that prefer source code outside of GitHub for compliance reasons.


The root cause lies in two lines of the app.ini file that the Gitea Docker image distributed by default. The REVERSE_PROXY_TRUSTED_PROXIES configuration was marked with the wildcard asterisk, allowing the service to trust the HTTP header X-WEBAUTH-USER coming from any IP address. An unauthenticated client, able to reach the public port of the container, sends this header with an administrative username and receives an admin session. Ali Mustafa, a researcher known as rz1027, discovered and reported the flaw; the fix removed the wildcard from the default configuration and turned authentication through reverse proxy into an explicit opt-in.


What Sysdig Observed


Michael Clark, Senior Director of Threat Research at Sysdig, stated in a note that the activity observed so far is at the initial investigation stage by the attacker and has not progressed to lateral movement or payload installation. "We believe we caught this early, before it had a chance to evolve beyond this phase," Clark declared. This point is significant because Gitea, unlike managed code repositories, typically resides within network segments containing secrets, SSH keys, and CI pipelines that communicate with production.


The window of silence between the June 20 patch and the first exploitation on July 3 is typical of the pattern that Sysdig and other researchers began mapping in 2026: attackers wait for the dust to settle, extract details from the commit that fixed the bug, and launch large-scale scans as most operators presume the wave has passed. Cyberdaily estimated that less than half of the exposed Gitea containers were updated to version 1.26.3 by the beginning of this week.


Where the Problem Hits: United States, Germany, and China


The installed base of Gitea is concentrated in three distinct geographies. In the United States, DevOps teams from startups and platform areas that moved away from GitHub due to cost or latency issues often run Gitea on private clouds. In Germany and the rest of the European Union, Gitea has become the preferred option for companies that need to keep source code within geographic boundaries under GDPR, including engineering divisions of automotive manufacturers and public integrators. In China, where access restrictions to GitHub and local data policies have pushed the community towards open forks, Gitea has gained traction in regional banks, universities, and state agencies; Gitee, a Chinese fork of the project, inherits the same code base and may share the issue in outdated versions.


In the U.S., the immediate risk is the theft of secrets and CI pipeline hijacking, which often leads to production access within hours. In Europe, the materialization of risk tends to be detection by the data protection authority: an attacker entering as an admin in a corporate Git is an event that triggers mandatory notification under GDPR within 72 hours. In Asia, where many installations still run versions prior to 1.24 without regular patch processes, the vector can remain open for weeks before any investigation.


What to Do Now


Administrators should first confirm the version in use. From version 1.26.3 onward, the default behavior has changed: REVERSE_PROXY_TRUSTED_PROXIES no longer comes with an asterisk and has become an explicit list. Those who have operated Gitea behind a legitimate reverse proxy need to manually re-add the trusted IPs. Those who discover that the service never required reverse proxy authentication can simply disable the feature.


Sysdig also recommends reviewing logs for requests with the X-WEBAUTH-USER header coming from outside the internal network and checking which deploy keys and CI tokens have been accessed in the past 20 days. In environments where Gitea stores pipeline secrets, the preventive rotation of credentials is less costly than triaging a confirmed incident. Version 1.26.3 has already been available for over two weeks. The remaining question is whether the next report will be about applied patch or incident response.

Lead Analysis