The Cybersecurity and Infrastructure Security Agency added a critical Gitea vulnerability to its Known Exploited Vulnerabilities catalog on August 25, 2026, confirming that attackers are already using it against real servers. The flaw, tracked as CVE-2026-60004 and rated 9.8 out of 10 on the CVSS scale, affects self-hosted Gitea instances running versions 1.17 through 1.27.0. A fix has existed since version 1.27.1 shipped in late July, but any team still running an older, internet-facing instance is exposed right now. Federal civilian agencies have until August 28 to patch under CISA’s binding directive.
This is the second major self-hosted git platform in less than two weeks to land on CISA’s radar. It follows a critical unauthenticated GraphQL flaw in GitLab, and adds to a rougher-than-usual month for self-hosted infrastructure that also included the Zimbra RCE bug disclosed just days earlier.
How the Gitea RCE Vulnerability Works
The bug sits in how Gitea processes patches through its diffpatch endpoint, inside a function in services/repository/files/patch.go. According to Gitea’s own security advisory, an attacker with ordinary write access to a repository can submit the same patch twice, forcing an add or add collision during the merge. Git’s three way fallback then checks out the colliding path even though the operation was supposed to stay cached only.
Because a bare repository treats its root directory as $GIT_DIR, that behavior lets an attacker plant an executable file exactly where Gitea expects a Git hook to live. The next time Git writes its index, that file runs, executing shell commands with the privileges of the Gitea service account. Gitea ships with open registration turned on by default, so on an unpatched instance with that setting untouched, anyone can sign up, create a repository, and have everything needed to trigger the exploit without a valid account handed to them.
Attackers Are Deploying Crypto Miners Right Now
Reporting from The Hacker News and Help Net Security describes an active campaign that kills competing processes, wipes environment variables, then downloads and runs a cryptocurrency miner matched to the server’s CPU architecture. One documented case pushed a compromised server past 70 percent CPU usage before anyone noticed. A miner is the visible symptom here, not the ceiling of what’s possible. The same shell access could reach database credentials, OAuth tokens, or any other secret sitting on that machine, so treating this purely as a mining infection undersells what an attacker with that foothold could actually pull off.
What to Do About It
- Upgrade to Gitea 1.27.1 or later immediately if you haven’t already.
- Set DISABLE_REGISTRATION to true unless open sign-ups are genuinely needed, and require email confirmation if they are.
- Check your instance’s CPU usage and running processes for anything unfamiliar, and review recently created repositories and accounts.
- Rotate any secrets the Gitea service account had access to if you can’t confirm the instance was patched before this week.
If your team runs any self-hosted developer tooling with public sign-ups enabled, this is a good prompt to check what else on that list hasn’t been patched in a while.
