CISA gave federal agencies three days to fix a critical Gitea remote code execution flaw. The clock ran out on 28 August; the day before, Shadowserver counted 8,393 vulnerable instances — and the entire public record of exploitation is one developer’s blog post about a high CPU alert.
What happened
CVE-2026-60004 is a remote code execution flaw in Gitea, the self-hosted Git service. NVD published the record on 26 August 2026, last modified it on 27 August, and lists it as Analyzed. The description, verbatim: “Gitea before 1.27.1 allows remote code execution via the diffpatch API through Git hook installation.” MITRE scored it CVSS v3.1 9.8, Critical, vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, CWE-94. Affected versions run from 1.17.0 through 1.27.0.
The federal timeline, from NVD’s republication of CISA’s catalog fields: cisaExploitAdd of 2026-08-25, cisaActionDue of 2026-08-28, catalog name “Gitea Code Injection Vulnerability.” That is a three-day clock under BOD 26-04, and it expired yesterday. CISA’s SSVC decision points on the record read Exploitation: active, Automatable: yes, Technical Impact: total.
The fix has been available for a month. Gitea 1.27.1 shipped on 27 July 2026, and the project’s security advisory, GHSA-rcr6-4jqh-j84m, went up on 28 July, credited to a researcher going by NightRang3r.
The mechanism is worth spelling out because it explains the exposure. The diffpatch endpoint lets a user apply a patch to a repository through the web interface. Submit the same patch twice and you produce an add/add collision. Git’s three-way merge fallback then checks out the indexed path despite the --cached flag. In a bare clone — which is how Gitea stores repositories — the repository root is $GIT_DIR, so a file written to hooks/post-index-change is not an inert file in a working tree. It is a live hook, and Git executes it during index operations.
The precondition, in the advisory’s own words: “An attacker with ordinary write access to a repository can execute arbitrary shell commands as the Gitea OS user.” And then the sentence that turns a privileged bug into a 9.8: “With open registration enabled, the attack can be performed by an unauthenticated visitor after registering a normal account and creating a repository.”
On 27 August, the Shadowserver Foundation’s scanning reported 8,393 IP addresses found vulnerable — one day before the federal deadline, one month after the patch.
Why it matters
Start with the exploitation evidence, because it is thinner than the SSVC value suggests and readers deserve to know what “actively exploited” is resting on here.
The public record we could find amounts to a single incident report, published on the Russian technical blog Habr by a full-stack developer describing his own organization’s self-hosted Gitea server. His hosting provider, HOSTKEY, flagged the machine for sustained CPU usage above 70 percent in breach of terms of service. Working backward, he determined that “an automated scanner was able to register an account, create its own repository, and trigger the exploit chain,” and that the active phase of the attack lasted roughly eleven seconds. On what was actually deployed, he is candid: “I do not have confirmed information regarding the mining pool, wallet, miner family, or specific operator.”
That is one host, one operator’s account, no vendor telemetry, no second observer, and no named payload family. Coverage has rendered it as cryptocurrency mining malware, which is a reasonable inference from a CPU alert and is not what the reporter says he can confirm. CISA’s catalog entry, as usual, does not cite its evidence, so we cannot tell whether the agency is working from this report or from something it has not published.
None of which means the listing is wrong. This is a case where the thin exploitation record and the aggressive federal clock are both defensible, and the reason is in the mechanism rather than the telemetry. The advisory shipped with a proof of concept. The attack requires no credential when open registration is on, which is a common configuration for internal and community instances. The whole chain — register, create repo, submit a patch twice — is three HTTP interactions a scanner can automate end to end, which is exactly what the Habr report describes happening in eleven seconds. Automatable: yes is the honest reading. When a bug is that cheap to fire, one confirmed hit and a published PoC really is enough to justify treating it as a live threat, because the gap between one and thousands is a scan cycle.
The more uncomfortable number is 8,393. A patch that has been public for a month, a CVSS 9.8, a proof of concept in the advisory, a federal deadline — and the day before that deadline, more than eight thousand instances still answering. Self-hosted Git is a specific kind of blind spot. It gets stood up by a platform team or a research group, it does not appear in a SaaS inventory or a software bill of materials, nobody has an agent on it, and it accumulates exactly the assets an attacker wants: source, CI configuration, deploy keys, and the tokens that let a build pipeline reach production. Code execution as the Gitea OS user on that box is not a mining problem. Mining is what you notice.
There is a second lesson in how the advisory reads. “An attacker with ordinary write access to a repository” is the first sentence, and taken alone it sounds like an insider-risk item — the kind of finding a team defers because everyone with repository access is already trusted. The open-registration clause that removes the precondition entirely is the sentence after. Gitea wrote both, plainly and in order, and the project deserves credit for that. But the sequencing matters when a busy administrator skims, and the 9.8 with PR:N is the score that reflects the second sentence, not the first. If your instance requires an administrator to create accounts, your practical exposure is genuinely lower than 9.8 implies. If it does not, the score is right and the first sentence is misleading you.
Finally, the deadline itself. It passed on 28 August, quietly: there is no published compliance figure and no notification anyone receives. For the many organizations that ingest KEV as a prioritization input, an elapsed due date sorts as lower priority in a lot of tooling, when it should sort as higher.
What to do
- Upgrade to Gitea 1.27.1 or later. Everything from 1.17.0 through 1.27.0 is affected — a range covering several years of releases, so “we are on a recent 1.2x” is not an answer.
- Find the instances first. Look for listeners on 3000/tcp, the Gitea default, and search DNS and reverse proxy configurations for
git.hostnames. The instance most likely to be unpatched is the one no inventory knows about. - Turn off open registration if you cannot upgrade immediately. In
app.ini, setDISABLE_REGISTRATION = trueunder[service]. This does not fix the bug — any authenticated user with write access to any repository can still trigger it — but it removes the unauthenticated path, which is the one the scanners are using. - Check for hooks nobody wrote. On each repository under Gitea’s data directory, inspect the
hooks/directory, and treatpost-index-changewith particular suspicion — Gitea does not normally place one there. Compare modification times against your patch date. - Look at CPU before you look at logs. In the one documented case, the alert came from the hosting provider, not from security tooling. Sustained unexplained load on a Git server is worth an hour of somebody’s time.
- Rotate what the box held. If you find evidence of execution, deploy keys, CI runner tokens, webhook secrets and any credentials in repository settings should be treated as disclosed. Patching returns the server; it does not return the secrets.
- FCEB agencies: the due date was 28 August. If you are not there, you are past it, and the remediation obligation does not lapse with the date.
Sourcing note
Checked: NVD’s API record for CVE-2026-60004, which supplied the description, CVSS v3.1 score and vector, CWE, affected range, and the CISA catalog fields — cisaExploitAdd 2026-08-25, cisaActionDue 2026-08-28, catalog name, and the SSVC decision points — as NIST republishes them verbatim from CISA. cisa.gov blocks automated fetching, so the catalog page itself was not read. Gitea’s security advisory GHSA-rcr6-4jqh-j84m on GitHub supplied the mechanism, the affected and patched versions, the researcher credit and both quoted sentences about write access and open registration.
Single-sourced and labeled as such: the exploitation account is one developer’s report on Habr, reaching us through Help Net Security and The Hacker News, both of 26 August, which agree on its substance. We did not read the Habr post directly. No vendor has published corroborating telemetry, no payload family is named by the reporter, and the characterization of the payload as a cryptocurrency miner is an inference drawn in coverage from a CPU alert, not a confirmed identification.
The figure of 8,393 vulnerable IP addresses on 2026-08-27 is the Shadowserver Foundation’s, reported by BleepingComputer on 28 August; we could not read Shadowserver’s own posting and carry the number as reported. It counts internet-reachable instances that answered a scan — a floor, not a census. Instances behind VPNs or reverse proxies are not in it, and are not therefore safe.
Unresolved: what evidence CISA relied on for the KEV addition, which is not published; whether any payload family has been identified; and what federal compliance with the 28 August deadline actually looks like, for which no figure exists.
