There’s a particular kind of irony that lives at the intersection of self-hosting and security. You pull your code from GitHub or GitLab because you want control, you want privacy, you want to own your infrastructure — and then you forget that “control” also means “you’re responsible for patching it.”
That irony has just become rather urgent.
The vulnerability
CVE-2026-60004 is a CVSS 9.8 (Critical) remote code execution flaw in Gitea, the lightweight, open-source Git hosting platform that thousands of organisations use precisely because they don’t want to trust a cloud provider with their source code. Salesforce security researcher Shai Rod (also known as NightRang3r) discovered that Gitea’s diffpatch API endpoint can be abused to plant a malicious Git hook. The mechanism is elegant in the way supply chain attacks tend to be: submit the same patch twice, force an “add/add” merge collision, and when Git’s three-way merge fallback kicks in on Git 2.32 or later, it checks out attacker-controlled content that executes arbitrary shell commands as the Gitea service account.
The catch? Gitea ships with open registration enabled by default. An attacker doesn’t need credentials — they just need to register an account, create a repository, and fire off a couple of API calls.
The timeline
Gitea patched this in version 1.27.1, released on July 27, 2026. For a month, the advisory sat there doing what security advisories do — gathering dust while administrators queued the update behind “after the release” or “next sprint.”
Then on August 26, CISA confirmed that CVE-2026-60004 was actively being exploited in the wild and added it to the Known Exploited Vulnerabilities catalog, giving federal agencies a hard deadline of August 28. The documented attacks have so far deployed cryptocurrency-mining droppers, but the same execution path that installs a cryptominer could just as easily harvest credentials, exfiltrate source code, or tamper with the very repositories Gitea exists to protect.
The scale
Shadowserver ran a scan on August 27 and found 8,393 internet-exposed Gitea instances still running vulnerable versions. The vulnerability affects every release from 1.17 through 1.27.0 — a span covering several years of production deployments. That means even if you installed Gitea “not that long ago,” you might still be sitting on it.
The self-hosting tax
This is the unwritten rule of self-hosting that gets glossed over in the blog posts: managed platforms absorb the security workload. When GitHub or GitLab find a vulnerability, they patch it. When Gitea finds one, you have to patch it. There’s nothing inherently wrong with that — the trade-off is the point — but the 8,393 figure suggests that “I’ll get to it next week” is the most common security strategy in the self-hosting world.
If you’re running Gitea, check your version now. Anything below 1.27.1 needs updating, and if your instance is internet-facing with open registration, you should probably assume it’s already been checked out by someone who isn’t you.
Sources: The Hacker News, Cloud Security Alliance, BleepingComputer, Gitea security advisory
