a Gitea admin's hosting bill flagged 70% CPU usage. that's how he found the hackers

CISA added a Gitea bug to its Known Exploited Vulnerabilities catalog on August 25, and the federal deadline to patch it is August 28 — three days. The vulnerability, CVE-2026-60004, lets anyone with a free account on an open-registration Gitea instance plant a git hook that runs as the server itself, no pre-existing credentials required. One admin found out the hard way: his hosting provider emailed him because his server had been pegged above 70% CPU for hours. It wasn't a backup job. It was a cryptominer.

How the diffpatch bug actually works

Gitea's diffpatch endpoint applies a submitted patch inside a temporary repository before showing you the diff. A specially crafted patch can smuggle a git hook — a script git runs automatically at certain points in its own lifecycle — into that temporary repo. When Gitea's internal git operations touch the repo afterward, the hook fires with the privileges of the Gitea service account. Researcher Shai Rod, who goes by NightRang3r, is credited with the discovery. The official fix, published as GHSA-rcr6-4jqh-j84m, landed in Gitea 1.27.1 on July 29.

The part that makes this worse than a normal RCE

Most RCE bugs need something first — stolen credentials, an admin account, a phished token. This one doesn't, if the install still has Gitea's default of open registration turned on. An attacker signs up for a free account, creates a repository, uploads a malicious patch, and waits for Gitea's own internal git housekeeping to trigger the hook. My honest take: this is the same failure pattern that's burned self-hosted git forges before — Gogs shipped a nearly identical path-traversal RCE a few weeks ago, and the fix there was just as blunt: patch, or disable public signup. If you're running either tool exposed to the internet with open registration on, you're one PoC copy-paste away from being the next HOSTKEY email.

Timeline: three weeks from patch to KEV listing

What actually happened on that one server

Andrey's account of it, picked up by The Hacker News, is a decent case study in how unglamorous most successful attacks are. His instance had open registration on, no email confirmation, OpenID signup enabled, and no sign-in requirement to view pages — a fairly common self-hosted setup for a small team that never expected to be a target. The payload wasn't sophisticated. It didn't need to be.

• Cleared environment variables to strip logging and monitoring hooks
• Enumerated running processes and killed anything already eating CPU, including competing miners
• Fetched an architecture-specific binary payload from an external host
• Executed it, then deleted itself from disk to reduce forensic evidence

What to do right now

This one's going to keep showing up in incident write-ups for a while, mostly because self-hosted git forges are exactly the kind of infrastructure that gets stood up once and then forgotten. If your team spun up a Gitea instance two years ago for a side project that's since become load-bearing, this is the week to go check its version number. We've been tracking the same pattern in other self-hosted dev tooling — n8n's authenticated RCE bug and the LiteLLM/Trivy supply-chain leak both trace back to the same root cause: internet-facing dev infrastructure nobody budgeted ongoing patch-cycle time for. It's also worth remembering that the people probing servers like this one increasingly aren't doing it by hand — see our look at how attackers are automating exploitation with AI for why 'small, obscure self-hosted tool' isn't the protection it used to be.