CISA added CVE-2026-60004, a critical remote code execution flaw in the self-hosted Git platform Gitea, to its Known Exploited Vulnerabilities catalog on August 25, confirming attackers are actively abusing it. Federal civilian agencies have until August 28 to remediate. The bug was patched more than a month ago in Gitea 1.27.1, but self-hosted instances lag patches far worse than SaaS, and this one is now tied to at least one confirmed cryptomining intrusion.

What happened

Gitea’s diffpatch API — the endpoint that applies a patch file to a repository — can be abused to plant an executable Git hook using content the attacker fully controls. A crafted patch causes Gitea to write a hook script into the repository’s hooks directory and then trigger its execution during normal repository operations. Because Git hooks run as the service account, not as the requesting user, this converts a repository write operation into arbitrary shell command execution as the Gitea OS user.

The access bar is low. Any account with ordinary write access to a repository can pull this off — no admin rights, no special API scope. On the large fraction of Gitea instances that ship with open self-registration enabled (the out-of-the-box default), an unauthenticated visitor can register an account, create a repository, and exploit the endpoint against their own repo to get code execution on the host. From there, lateral movement depends on what else runs on that box: CI runners, deploy keys, and secrets stored in Gitea’s own database (SSH signing keys, OAuth app secrets, webhook tokens) are all typically reachable once the service account is compromised.

CVE-2026-60004 carries a CVSS score of 9.8. Gitea credits security researcher Shai Rod (NightRang3r) with the report.

Affected versions

Every Gitea release from 1.17 through 1.27.0 is vulnerable. Gitea shipped the fix in 1.27.1, released July 27, 2026, with the security advisory published the next day. Forgejo, the Gitea fork, is built on a divergent codebase for this component and has not been confirmed vulnerable in current reporting — but instances tracking upstream Gitea releases closely should verify their fork lineage rather than assume safety.

Active exploitation

An incident writeup published on the Russian collaborative blog Habr describes an organization’s self-hosted Gitea instance being compromised via this flaw and used to deploy cryptocurrency-mining software. That’s consistent with the opportunistic pattern typical of scanner-driven exploitation against a wide pool of self-hosted, internet-facing targets rather than a targeted campaign — though a compromised CI/CD host is just as useful for supply-chain tampering as it is for mining, and defenders should not assume mining is the only payload attackers are running.

CISA’s KEV addition on August 25 is the strongest public confirmation that exploitation is occurring beyond isolated anecdotes, and the compressed August 28 remediation deadline for federal systems signals the agency views this as an active, spreading threat rather than a one-off.

Mitigation

  • Upgrade to Gitea 1.27.1 or later immediately. This is a one-line fix on the defender side: there is no viable compensating control for the diffpatch code path short of patching.
  • Disable open self-registration (DISABLE_REGISTRATION = true in app.ini) if your instance doesn’t need it. This removes the unauthenticated-to-write-access path entirely and is good hygiene regardless of patch status.
  • Audit hooks directories on any unpatched instance for unexpected scripts under <repo>/hooks/, and review process history and outbound network connections on the Gitea host for miner-like behavior (unexpected CPU load, connections to mining pool endpoints).
  • Rotate secrets stored in Gitea — SSH keys, OAuth client secrets, webhook signing secrets, and any deploy tokens — if you find evidence of exploitation or were running an affected version with open registration enabled.
  • Check internet exposure. If your Gitea instance is reachable from the public internet and doesn’t need to be, put it behind a VPN or IP allowlist; this endpoint doesn’t require any special privilege to reach.

References