The bug lives in a feature most Gitea admins never think about twice: the diffpatch endpoint that lets a repository collaborator apply a patch through the web UI instead of the command line. Gitea processes that submission by cloning the target repository into a temporary bare copy, which is normally the safe choice - bare repositories don't run hooks. The flaw is that submitting the same specially crafted patch twice let an attacker plant a file at hooks/post-index-change inside that temporary clone, and Gitea would execute it as the Gitea service account. No admin access required, just standard write access to a repository. Researcher Shai Rod reported it, Gitea credited him by name in the release notes, and the fix - changing the temporary clone from bare to non-bare so the hook path can't fire - shipped in version 1.27.1 on 27 July, with versions 1.17 through 1.27.0 affected.
The part that makes it worse: you don't need an account first
Gitea ships with open self-registration enabled by default, and a lot of self-hosted instances never turn it off. That means the CVE-2026-60004 attack chain doesn't require compromising an existing account or social-engineering a maintainer - an anonymous visitor can register, create a repository, and submit the crafted patch twice, all without ever needing credentials that belonged to someone else. It's the same pattern that keeps showing up in write-access vulnerabilities on self-hosted developer tools: the barrier to entry isn't a stolen password, it's a signup form nobody remembered to lock down.
A month of quiet, then a proof-of-concept changed the calculus
Gitea's advisory went out on 28 July, a day after the patch. For roughly three weeks, nothing public tied CVE-2026-60004 to real attacks. That changed when a developer described, in a post on the Russian collaborative blog Habr, an attack against their own outdated, open-registration Gitea instance - Help Net Security's write-up puts the full compromise, from the malicious patch submission to a cryptomining payload running on the server, at around eleven seconds. A working proof-of-concept exploit was published publicly on GitHub not long after, and CISA confirmed active exploitation and added the CVE to its Known Exploited Vulnerabilities catalog on 25 August, with the standard three-day remediation window for federal civilian agencies - a deadline that lands on 28 August, exactly a month after the fix shipped.
What's actually reachable once someone's in
Because the malicious hook runs as the Gitea OS user rather than in some sandboxed context, a successful exploit can reach whatever that account can: configuration files, stored secrets, database credentials, and any integration tokens the instance holds for CI/CD or other connected services. For a lot of organisations, Gitea isn't just source control - it's the thing holding the keys to the pipeline that deploys everything else, which is exactly why an eleven-second cryptomining compromise is the mild version of what this bug allows.
- Upgrade every Gitea instance to 1.27.1 or later now - a public PoC exists, so treat this as actively targeted rather than theoretical.
- Turn off open self-registration unless there's a genuine business reason to keep it on, and require email verification if you do.
- If you can't confirm exactly when an instance was patched relative to late July, rotate any secrets, database credentials and CI/CD tokens it held access to.
- Check hook directories and recent diffpatch activity in your logs for anything unexpected, particularly duplicate submissions of the same patch.
- Don't treat an internally-hosted Git server as lower priority than internet-facing services - this attack path doesn't require pre-existing credentials.
A one-line changelog credit and a quiet security advisory rarely get the attention a CVSS 9.8 deserves until a proof-of-concept and a CISA deadline force the issue. If you'd like help auditing where your own Gitea or self-hosted Git estate stands against this one, email sales@halfteck.com.