CVE-2026-60004: Gitea's diffpatch RCE Is Now Being Exploited

Gitea is the self-hosted Git server a lot of teams reach for instead of paying for GitHub Enterprise or running a GitLab instance nobody wants to maintain. That makes CVE-2026-60004 an uncomfortable one: a CVSS 9.8 remote code execution bug in Gitea’s diffpatch API that turns a crafted merge conflict into a shell on the box hosting your source code. CISA added it to the Known Exploited Vulnerabilities catalog on August 25 after reports of compromised instances running crypto miners, and gave federal agencies until August 28 to patch. If you self-host Gitea and haven’t checked your version this week, do it before you finish reading.

What’s actually broken

The diffpatch API exists to let Gitea apply a submitted patch against a repository, the kind of thing that happens routinely when a pull request gets merged. It does the work inside a temporary Git clone, applies the patch, and cleans up.

The bug is in how that temporary clone is structured. A crafted patch can force an add/add collision, a specific kind of merge conflict where two sides of a merge both introduce the same new file. Git resolves that with a three-way merge fallback, and that fallback is where the attack lands: it lets attacker-controlled content get written into a location that becomes an executable Git hook, specifically a post-index-change hook.

Here’s the part that turns a weird merge quirk into remote code execution. The temporary clone diffpatch uses is a bare repository, but its working directory and its Git directory are the same location. A hook written into that directory isn’t sitting in some inert temp folder. It’s live, in the one place Git will actually execute it from, and the next index operation on that clone triggers it. The hook runs as the operating system account that runs the Gitea service, with whatever file access and network reach that account has.

Gitea fixed this in 1.27.1 by changing that temporary clone from a bare repository to a non-bare one, which breaks the specific overlap between working directory and Git directory that made the hook active. The fix shipped as pull requests #38637 and #38638 upstream.

Why “requires write access” doesn’t mean what it sounds like

The diffpatch endpoint requires repository write permission, which on paper sounds like a meaningful barrier. It isn’t one in practice, because Gitea ships with self-registration enabled by default. An attacker with zero prior access can create an account, create a repository they fully control, and call the vulnerable endpoint against their own repo. There’s no privileged access to steal and no social engineering required. The only real gate is whether your instance still has open registration turned on, and most do, because closing it is a deliberate opt-out step most admins never think to take.

That’s the same pattern that keeps showing up in this category of bug: an authorization check that’s technically present but sits behind a door anyone can walk through. It’s worth comparing to TeamCity’s unauthenticated RCE from earlier this year, where the barrier was missing entirely rather than trivially bypassable. Different mechanism, same outcome: a tool your whole engineering org trusts by default turns out to be reachable by anyone who can reach it at all.

The timeline

The flaw was first disclosed publicly in July 2026, alongside the release of Gitea 1.27.1 carrying the fix. For a few weeks, this looked like a routine patch note. That changed by late August, when reports began surfacing of compromised self-hosted Gitea instances running crypto-mining payloads, consistent with an attacker using the flaw for opportunistic access rather than anything targeted. CISA added CVE-2026-60004 to its KEV catalog on August 25, which is the point where “you should patch this” becomes “assume you’re already a target if you’re exposed.”

The gap between disclosure and confirmed exploitation here was measured in weeks, not days, which is actually the more common pattern than the 24-hour turnarounds that make headlines. It’s also the more dangerous one for defenders, because a slower burn gives a false sense that the window has closed when it hasn’t. A patch that sat in your backlog for a month because “nothing’s happened yet” is exactly the kind of gap this bug was built to exploit.

What to do

1. Check your Gitea version. Anything before 1.27.1 is vulnerable. Upgrade now if you’re behind.
2. Turn off open self-registration unless you have a specific reason to keep it on. It’s the single control that turns this from “needs an insider” into “needs an internet connection.”
3. Audit recent repositories and accounts for anything you don’t recognize, especially ones created in the last month with unusual patch or merge activity.
4. Check the host for signs of compromise, particularly unexpected processes, elevated CPU usage consistent with mining, or outbound connections you can’t explain. Patching closes the door; it doesn’t reverse anything that already walked through it.

Self-hosted developer tooling keeps landing on the KEV list for the same structural reason: it’s software your team didn’t write, it usually runs with more privilege than anyone budgets for, and it rarely gets the same review cadence as the application code sitting next to it. If Gitea, Jenkins, or a similar tool is part of your stack, a periodic security review that specifically inventories self-hosted infrastructure and its exposure is cheaper than finding out about a gap from a KEV alert.