Gitea RCE (CVE-2026-60004) Exploited to Hijack Servers for Crypto Mining

Attackers are actively exploiting a critical-severity vulnerability in the Gitea self-hosted Git service, tracked as CVE-2026-60004. It stems from the way Gitea's diffpatch endpoint handled the temporary Git repository used to process incoming patches. Vulnerable releases built that workspace as a bare clone, in which the repository directory itself doubles as Git's internal data directory, the location where Git hooks are stored. When a patch is applied, Gitea runs a Git apply operation with a three-way merge fallback. Submitting the same patch twice creates an add/add collision, and Git's fallback writes the conflicting file into the checked-out path even though the operation targets the index. In a bare clone that path resolves inside the Git directory, so an executable file named hooks/post-index-change lands exactly where Git expects a live hook. Git then invokes it while writing the index, and the attacker's content runs as the Gitea service account, giving the attacker full remote code execution on the Gitea host.

The vulnerable API call requires an authenticated user with repository write permission, but in practice that bar is low. Gitea's default configuration enables self-registration, frequently without administrator approval or email confirmation, and lets new users create repositories. An external attacker can therefore register, create a repository, and reach the diffpatch endpoint over HTTPS. That is precisely the path described in the one publicly reported intrusion, where the server's SSH was never exposed and the attack arrived entirely over the web interface, underscoring how a Gitea remote code execution chain can begin with nothing more than an open registration form.

Every Gitea release from 1.17 up to but not including 1.27.1 is affected. Exploitation also depends on a few server-side conditions: a Git version new enough to support the relevant three-way fallback behavior (2.32 or later), an enabled diffpatch route, and a temporary filesystem where the Gitea service can both write and execute files. These conditions mean not every vulnerable instance is exploitable through the identical chain, but default deployments frequently line up, which keeps the real-world exposure to CVE-2026-60004 high.

Notably, CVE-2026-60004 was not exploited as a zero-day. The patch shipped in late July, and confirmed abuse surfaced roughly a month afterward. Separately, an administrator publicly documented an intrusion in which an unknown actor exploited the flaw over HTTPS to run a dropper that behaved like a cryptocurrency miner, driving CPU usage high enough that the hosting provider throttled the server. The payload was never fully analyzed, so it is best described as miner-like rather than tied to a named family. Given the confirmed exploitation, the availability of a public proof-of-concept, and code execution as the Gitea service account, organizations running any affected version should upgrade to Gitea 1.27.1 immediately to close off this crypto mining infection vector.