Critical Gitea Vulnerability CVE-2026-60004 Exploited for Crypto-Mining

Critical Gitea Vulnerability CVE-2026-60004 Exploited for Crypto-Mining

A critical vulnerability in Gitea, the popular self-hosted Git service, is being actively exploited to drop cryptocurrency miners on vulnerable servers. The flaw, tracked as CVE-2026-60004, allows an attacker to inject code through the platform's diffpatch endpoint and install malicious Git hooks that execute arbitrary shell commands as the Gitea operating system user.

The vulnerability is especially concerning because of how easily it can be reached. An attacker with write access to a repository can trigger the code injection, and in many Gitea deployments, write access is trivially obtainable. Instances that allow open registration without CAPTCHA protection effectively expose an unauthenticated path to exploitation — anyone can sign up, create a repository, and launch the attack.

A Real-World Incident

Security researchers documented a concrete incident in which an automated scanner exploited the vulnerability to drop a cryptocurrency miner. The entire attack — from initial probe to active mining — took just 11 seconds. That speed illustrates how fully automated the exploitation has become: there is no human attacker carefully crafting a payload, just a bot scanning the internet and firing off a pre-built exploit the moment it finds a vulnerable target.

The incident also revealed a nuance worth noting. The compromised Gitea instance was running inside a container, and that isolation did help limit the blast radius of the attack. However, it did not prevent the compromise itself. Containerization is a useful defense-in-depth measure, but it is not a substitute for patching the application running inside the container.

Patches and Deadlines

The vulnerability was patched in Gitea v1.27.1, with the latest release now at v1.27.2. CISA has added CVE-2026-60004 to its Known Exploited Vulnerabilities (KEV) catalog, a designation reserved for flaws that are being actively exploited in the wild. Federal agencies have been given a deadline of August 28 to remediate.

For the broader community, the KEV listing is a strong signal that this is not a theoretical risk. When a vulnerability lands on the KEV catalog, it means CISA has confirmed real-world exploitation, and the clock is ticking for everyone who runs the affected software — not just government agencies.

Why Self-Hosted Git Services Are Attractive Targets

Gitea and similar self-hosted Git platforms are appealing to attackers for several reasons. They often contain source code, credentials, and deployment configuration that can be leveraged for further attacks. They also tend to be run by smaller teams or individual developers who may not have the same patching discipline as large enterprises.

The diffpatch endpoint vulnerability is a reminder that Git services are not just version control tools — they are application servers with their own attack surface. Features like patch application, webhooks, and Git hooks all execute code in some form, and any of them can become a vector if not carefully validated.

Git hooks are a particularly powerful target because they are designed to run arbitrary commands at key moments in the Git workflow — on commit, on push, on merge. By injecting a malicious hook through the diffpatch endpoint, an attacker turns the repository's own automation machinery against the server, gaining persistent code execution that survives reboots and re-deployments.

What Should You Do?

If you run Gitea, upgrade to v1.27.2 immediately. Do not wait for a convenient maintenance window — the exploit is automated and scanning is constant. If you cannot patch right away, disable open registration and require CAPTCHA or manual approval for new accounts, which closes the unauthenticated path to the vulnerability.

After patching, audit your Gitea instance for signs of compromise. Check for unexpected Git hooks in your repositories, review running processes for cryptocurrency miners, and inspect your server's CPU usage for unexplained spikes. If you find evidence of compromise, treat the entire instance as untrusted and rebuild it from a clean state rather than attempting to surgically remove the miner.

Sources