Gitea's diffpatch Endpoint Turns Any Repo Writer Into Root: Patch It Today, CVE-2026-60004 Is on KEV

The short version//

Gitea — the self-hosted Git service a lot of us run exactly because GitHub feels too much like a corporation — just got a CVSS 9.8 RCE that's being exploited right now. CISA added CVE-2026-60004 to the KEV catalog on 2026-08-25 with a federal remediation due date of today, 2026-08-28. If you run Gitea (or its fork, Forgejo) and you're not on 1.27.1, the clock is not being kind to you.

The exploit chain, in plain English//

The flaw lives in Gitea's diffpatch API endpoint — the part that applies a patch to a repository. Here's the shape of it:

• Gitea applies attacker-controlled patches in a shared bare temporary clone using git apply --index --cached.
• If Git is 2.32 or newer, it adds a -3 (three-way) fallback argument.
• An attacker with repo write access submits the same patch twice, creating an add/add collision. Git's three-way fallback then checks out the conflicted path into the index even though the command ran with --cached.
• In a bare clone, the repo root is $GIT_DIR. So a planted file at hooks/post-index-change lands in the exact spot Git looks for executable hooks.
• Git runs that hook while writing the index. Now the attacker is executing arbitrary shell commands as the Gitea OS user.

That's the whole trick: a patch endpoint that's supposed to store code accidentally ran code, because of an edge case in how Git's three-way merge handles --cached.

Why "just any visitor" is the worst part//

The base requirement is repo write access — which a lot of people have. But with Gitea's default open registration, an unauthenticated stranger can:

1. Register a free account,
2. Create a repo,
3. Submit the malicious patch,

…and they're running as the Gitea service account. No prior credentials, no invite, no nothing. The PoC the reporter shipped even keeps the attacker air-gapped: it stores command output in a Git object, pushes a branch, and reads it back over authenticated smart HTTP — no outbound call home needed.

What the attacker gets//

RCE as the Gitea service account (classified CWE-94, code injection) means, depending on how you've isolated your deployment:

• app.ini and Gitea's application secrets
• Process-environment secrets
• Every mounted repository
• Database credentials and the DB contents
• OAuth and integration credentials
• Lateral movement into whatever else trusts that host

The numbers that should bother you//

• ~5,000 Gitea instances are exposed to the internet per Shadowserver (some are honeypots, who knows how many are already pwned).
• Active exploitation in the wild is being attributed to crypto-miner deployment on unpatched boxes.
• The fix has been available since Gitea 1.27.1 (released 2026-07-27) — so this is a patched-but-unpatched-by-you story, which is always the worst kind.

What you should do//

1. Upgrade to Gitea 1.27.1 or later (and Forgejo to a corresponding patched release — check that changelog separately, the fork doesn't always track the parent version).
2. Turn off open registration if you don't genuinely need it. This doesn't fix CVE-2026-60004, but it stops the no-prior-credentials path and is a hardening win on its own.
3. If you can't patch today, disable or restrict the diffpatch route, or firewall the instance until you can.
4. Assume compromise if you were exposed — look for unexpected processes, new Git branches you don't recognize, and miners eating your CPU.
5. Read the vendor GHSA, not just the news headline. The git apply -3 --cached detail is exactly the kind of thing that tells you why the patch matters.