CVE-2026-60004 Explained: Gitea Diffpatch Code Injection Exploited to Achieve Remote Code Execution

Teams choose to self-host a Git service like Gitea specifically to keep source code, build pipelines, and often proprietary intellectual property off a third-party cloud platform. That same self-hosted posture means a vulnerable Gitea instance is frequently sitting closer to the crown jewels, application source code, CI/CD credentials, deployment secrets, than a typical internet-facing web application would be. A code injection flaw that lets an attacker run commands as the Gitea service account on that host is not a cosmetic bug in an admin panel; it is a foothold directly inside the software supply chain.

The severity here comes from how little an attacker needs to start. CVE-2026-60004 is documented as requiring only repository write access, and Gitea's own default configuration hands that write access to anyone who registers an account, a two-minute task on an instance that has not disabled self-registration. Submit one crafted patch to the diffpatch endpoint, submit it a second time, and the target Gitea host writes and executes an attacker-controlled file from inside Git's hook directory. CVSS scores this at 9.8, and the active exploitation CISA confirmed shows that score is not theoretical.

Treat any internet-reachable Gitea instance as a priority asset until you have confirmed both its version and its self-registration setting. If your organization already tracks CISA KEV entries against its own asset inventory, this is a direct candidate for that workflow; see our guide on cross-referencing asset inventory against the CISA KEV catalog if that process is not already in place. Teams that also run GitHub or GitLab alongside a self-hosted Gitea instance should use this disclosure as a prompt to review hardening across the whole Git estate, not just the one platform named in the CVE; our GitHub organization security hardening checklist covers the equivalent access-control settings worth auditing on that platform.

CVE-2026-60004 affects Gitea, the self-hosted Git service and lightweight alternative to GitHub or GitLab. The vulnerability is tracked as a code injection flaw (CWE-94) in the diffpatch API endpoint, carrying a CVSS score of 9.8. According to reporting corroborated across multiple independent write-ups, the flaw is present in Gitea versions from 1.17 through 1.27.0.

Gitea fixed the issue in version 1.27.1, released July 27, 2026, with a security advisory published the following day. Our own research did not directly pull the exact commit or the full version matrix from Gitea's own GHSA advisory page, so treat the 1.17 through 1.27.0 range cited above as the starting point for your own audit rather than the final word. Confirm your specific prior version against Gitea's own release notes and security advisory before assuming an update from any version in that range to 1.27.1 fully closes the gap.

If your environment runs any Gitea instance on a version earlier than 1.27.1, treat it as vulnerable regardless of whether self-registration currently appears disabled, since the correct combination of write access and diffpatch access can also come from a compromised legitimate account rather than a freshly self-registered one.

Exploitation of CVE-2026-60004 is confirmed, not theoretical. CISA added the CVE to its Known Exploited Vulnerabilities catalog on August 25, 2026, an action CISA takes only against its own confirmed-exploitation standard, and set a remediation deadline of August 28, 2026 for federal civilian executive branch agencies under Binding Operational Directive 26-04, a three-day window that signals how urgently CISA weighed the real-world risk. NVD carries a corresponding entry for the CVE.

Reporting from The Hacker News points to at least one concrete incident: an administrator described, in a post to the Russian collaborative blog Habr, that their self-hosted Gitea instance was compromised through this vulnerability and used to run crypto-mining software, consistent with the "miner-like payload" language used in that coverage. That is a real, described incident, but it is a single account from a single affected party rather than a broadly attributed campaign, and our data does not tie it or any other exploitation activity to a named threat actor or intrusion set.

Separately, Shadowserver's internet-wide scanning found approximately 8,393 Gitea instances still vulnerable and exposed to the internet as of around August 27, 2026, which is a measure of unpatched exposure rather than a count of confirmed compromises. Both figures matter for different reasons: the KEV listing and the Habr-reported incident confirm exploitation is real, while the Shadowserver count shows how much of the remaining internet-facing attack surface has not yet closed the gap.

Detection for this vulnerability centers on two behavior categories: abnormal use of the diffpatch endpoint itself, and file writes or process spawns originating from Gitea's Git hook directory rather than a normal deployment or CI process. Our platform maintains a detection rule covering the diffpatch exploitation pattern behind CVE-2026-60004, translated into vendor-specific variants for Splunk, Elastic, Microsoft Sentinel and Defender, CrowdStrike, SentinelOne, Cortex XDR, QRadar, and Chronicle, alongside the underlying Sigma rule.

If your organization runs Gitea and forwards its application and host logs into a SIEM, prioritize repeated diffpatch API calls from the same account or session in a short window, since the exploit chain requires submitting the malicious patch twice, and any file creation event inside a Git repository's hooks directory that was not produced by your own deployment tooling. Host-level process monitoring that flags the Gitea service process spawning an unexpected child process is a closer proxy for successful exploitation than API-layer logging alone. Teams evaluating where to route this kind of detection content, or standing up a SIEM for the first time specifically because a self-hosted Git platform now needs its own log pipeline, may find it useful to review hardening across the broader source-code hosting estate; our guide on detecting supply chain compromise in software build pipeline security covers the adjacent build-and-release telemetry worth collecting alongside Gitea's own logs.

Retrospective hunt queries covering both the repeated diffpatch call pattern and historical Git hook directory writes are also available across the same vendor set, for teams that want to sweep back through existing logs to rule out prior exploitation rather than rely solely on a forward-looking alert.

Work through the following before deciding whether this is a routine patch item or something that needs incident response attention in your environment.

CISA's standard KEV guidance applies directly here: apply the vendor's fix, follow the risk-based prioritization described in Binding Operational Directive 26-04, evaluate internet exposure of every affected instance individually, and take an instance offline if it cannot be patched or otherwise mitigated while remaining internet-facing.

The most consequential gap in our data is attribution and the scope of exploitation. CISA's KEV listing and Shadowserver's exposure scan both confirm this vulnerability is real and being actively exploited, and The Hacker News reported one specific incident involving crypto-mining deployment, described secondhand through a Habr blog post from the affected party. Beyond that single account, our data does not identify a named threat actor, intrusion set, or a broader count of confirmed victim organizations. Next step: monitor CISA's KEV catalog entry and reputable incident response reporting for updates, and treat any broader attribution or victim-count claim you encounter elsewhere with skepticism until a named vendor, CISA, or an incident response firm confirms it directly.

Second, our data does not include a full public technical writeup or proof-of-concept walking through the exact diffpatch request sequence, only the general mechanism described by Gitea's own advisory and secondary reporting: a malicious patch submitted twice results in an executable written to and run from Git's hook directory. The detection and hunt guidance above is built from that behavior-level description rather than a vendor-verified signature matched against a captured exploit sample. Next step: use the log review categories above as a starting hypothesis and tune thresholds against your own environment's normal Gitea traffic before treating any single alert as a clean confirmation.

Third, the affected version range of 1.17 through 1.27.0 comes from secondary reporting rather than our own direct read of Gitea's official GHSA advisory or changelog. Next step: confirm your exact prior version and the precise patched build against Gitea's own security advisory and release notes before closing out remediation, rather than relying solely on the range cited in this article.

Finally, the Shadowserver figure of roughly 8,393 vulnerable exposed instances is a point-in-time snapshot from around August 27, 2026, and internet exposure changes daily as organizations patch or take instances offline. Next step: treat that number as a general indicator of how much exposure remained shortly after KEV listing, not as a live count, and rely on your own asset inventory and scanning to determine your organization's current status.