CVE-2026-60004: Gitea's diffpatch endpoint turns an attacker-supplied patch into a live Git hook, giving command execution as the service account; KEV-listed after miner deployment

CISA added CVE-2026-60004 to the Known Exploited Vulnerabilities catalog on 2026-08-25. The flaw is in services/repository/files/patch.go, the code behind Gitea's diffpatch endpoint, which applies an attacker-controlled patch inside a shared bare temporary clone. The maintainers describe the chain precisely: "submitting the same patch twice creates an add/add collision. Git's three-way fallback checks the indexed path out even though the operation is performed with --cached" (Gitea maintainers, 2026-07-28). In a bare clone the repository root is $GIT_DIR, so a checked-out executable entry whose path matches a Git hook name is not a file sitting next to the hooks directory, it is a hook. Git then invokes it while writing the index, and it runs as the Gitea OS account.

The precondition is the part worth reading twice. The advisory states it plainly: "an attacker with ordinary write access to a repository can execute arbitrary shell commands as the Gitea OS user. With default open registration, an unauthenticated visitor can obtain the required write access by registering an account and creating a repository" (same advisory). Ordinary write access is not a privileged role, it is what every user of a Git forge has by definition, and Gitea's shipped default hands it to anyone who can reach the login page. So on a default-configured instance this is a pre-authentication flaw in every sense that matters operationally, separated from an anonymous visitor only by a registration form. Fixed in Gitea 1.27.1. The advisory carries a working proof-of-concept, which arrived with it.

Exploitation is opportunistic and automated. Help Net Security reports the incident write-up of an operator whose self-hosted instance was compromised: "because the server ran an outdated version of Gitea, with open user registration and no email confirmation or CAPTCHA, an automated scanner was able to register an account, create its own repository, and trigger the exploit chain" (Help Net Security, 2026-08-26). The chain wrote a proof of execution into a Git branch, then pulled a shell loader followed by a miner; the operator was alerted not by security tooling but by the hosting provider flagging sustained CPU. That is a mass-scanning profile against a default configuration, not targeted intrusion, and it means exposure is a function of being reachable rather than being interesting.

The blast radius is broader than the payload suggests. Depending on container isolation and the privileges of the Gitea OS user, exploitation can expose the main configuration file, application and process-environment secrets, database credentials and contents, and OAuth and integration credentials (same reporting). A miner is the noisy outcome; the quiet one is a set of credentials into whatever the forge is wired to, which for a public-sector development estate typically means CI runners, artefact registries and identity providers.

Where the activity surfaces. The exploitation itself looks like ordinary API traffic, so the durable signal is what the service account does immediately afterwards. Watch for the Gitea service account spawning a shell or an interpreter within seconds of a patch or diff API call, on a host whose normal process tree is a Go binary plus git. On the repository side, the artefact is a Git hook whose content arrived through patch application rather than through an administrator action, so an executable object at a hook path in a repository nobody manages is the thing to hunt for. Registration and repository-creation events are the leading indicator: on an instance with real users, a self-registered account creating a single repository and immediately exercising the diff endpoints is not a normal usage pattern.

Triage: the benign lookalike is a legitimate developer using diffpatch to apply a patch, which is what the endpoint is for and which will be the overwhelming majority of hits on that route. Two things separate exploitation from it. First, the same patch applied twice in quick succession, which is the collision the attack requires and which a human working normally has no reason to produce. Second, and more reliably, what happens next: a legitimate patch application ends with a commit, while this one ends with the service account executing something. Alert on the process behaviour, use the endpoint traffic to explain it.