"Gitea's diffpatch endpoint can be abused to install and execute a Git hook from repository-controlled content," according to an advisory released by Gitea last month.
CISA warning and the Known Exploited Vulnerabilities listing
The U.S. Cybersecurity and Infrastructure Security Agency (CISA) on Tuesday warned of active exploitation attempts targeting a recently patched critical flaw in Gitea, and added the bug to its Known Exploited Vulnerabilities (KEV) catalog. CISA described the issue as a "code injection vulnerability" that allows attackers with repository write access to send a malicious patch to the diffpatch API endpoint to plant an executable Git hook and run shell commands as the Gitea service account. The agency did not disclose details about who is exploiting the flaw or how extensively it has been used in the wild.
The vulnerability, CVE-2026-60004, and its mechanics
The flaw is tracked as CVE-2026-60004 and carries a CVSS score of 9.8. According to Gitea's advisory, it is a remote code execution vulnerability that permits an attacker with ordinary write access to execute arbitrary shell commands as the Gitea OS user. The affected API is the "diffpatch" endpoint, which can be abused to install and execute a Git hook from repository-controlled content. The vulnerability impacts all Gitea versions from 1.17 and was patched in version 1.27.1. Security researcher Shai rod (aka NightRang3r) is credited with discovering and reporting the issue.
Audit-ready is a season. It shouldn't be.
Evidence in spreadsheets, controls drifting between audits, frameworks multiplying on flat headcount. Nubivance runs continuous compliance on Rapid7 Cyber GRC - SOC 2, HIPAA, ISO 27001, PCI, CMMC.
End the scrambleHow default settings enlarge the attack surface
Gitea's default configuration — specifically open registration — makes exploitation practical for external actors because it allows unauthenticated visitors to obtain the required write permissions simply by registering and creating a repository. As The Hacker News reported, the vulnerable API still requires repository write permission, but open registration means an attacker does not need pre-existing credentials to gain that permission. Gitea itself noted the risk in its advisory: "With default open registration, an unauthenticated visitor can obtain the required write access by registering an account and creating a repository."
Observed exploitation: HOSTKEY notice and the miner-like dropper
A full-stack developer identified as Andrey (aka @Causelof) published an analysis on Habr documenting an apparent exploitation of CVE-2026-60004 against their Gitea instance. The incident surfaced when hosting provider HOSTKEY emailed the developer, warning that the virtual server had been using more than 70% of processor capacity for an extended period and temporarily limiting CPU resources for the VPS. Andrey reported the following Gitea configuration at the time:
- DISABLE_REGISTRATION = false
- REGISTER_EMAIL_CONFIRM = false
- ENABLE_OPENID_SIGNUP = true
- REQUIRE_SIGNIN_VIEW = false
Andrey emphasized the importance of open registration: "The fact that open registration is enabled here is significant precisely because of its connection to the vulnerability." They also said Gitea's SSH was not exposed and that the attack vector was via HTTPS.
Before deploying what Andrey described as a "miner-like payload," the dropper script reportedly performed a sequence of steps: it cleared LD_PRELOAD and LD_LIBRARY_PATH, searched for high-CPU processes, attempted to kill competing processes, fetched a payload appropriate to the system architecture, downloaded and wrote it to disk, ran it, and then deleted the file after execution. Andrey did not analyze the next-stage payload and stated, "I do not have confirmed information regarding the mining pool, wallet, miner family, or specific operator." Nevertheless, the CPU spike observed by the hosting provider aligns with cryptojacking activity targeting vulnerable Gitea instances.
Mitigation steps, the patch deadline, and remaining questions
Gitea patched the vulnerability in version 1.27.1; versions from 1.17 are affected. CISA has included the flaw in its KEV catalog and directed federal agencies to address it, with agencies required to patch the flaw by August 28, 2026, while prioritizing updates on a risk-based approach. CISA did not provide additional public details about ongoing exploitation or attribution, and it remains unclear whether the agency's KEV listing was triggered specifically by the incident published by Andrey or by other evidence of exploitation against unpatched Gitea servers in U.S. federal environments.
What this means for federal agencies, Gitea administrators, and hosting providers
- Federal agencies: Must prioritize and complete patching by August 28, 2026, per CISA direction, using a risk-based approach to sequence updates.
- Gitea administrators: Need to apply the 1.27.1 patch if running affected versions and consider tightening registration-related settings (for example, disabling open registration or enabling email confirmation) to reduce the ease with which an external actor can obtain repository write access.
- Hosting providers: Should monitor for sustained high-CPU usage that can indicate cryptojacking and notify customers promptly; resource limits or throttling may expose ongoing compromise as in the HOSTKEY notification to Andrey.
The record is concrete on how the vulnerability works and how a dropper behaved on one observed instance, but it leaves open who is behind active exploitation and how widespread successful compromises are. With the KEV listing in place and a federal patch deadline set for August 28, 2026, administrators and custodians of Gitea installations now face a narrow window to apply the published fix and harden default registration settings to reduce the simple attack path described by Gitea and documented by Andrey.
