CISA has confirmed that CVE-2026-60004, the critical Gitea vulnerability we covered last month, is being actively exploited. The agency added the flaw to its Known Exploited Vulnerabilities (KEV) catalog on August 25, 2026, moving it from “patch when convenient” to “patch now” for anyone still running a vulnerable Gitea instance.
Federal civilian agencies had until August 28, 2026 to remediate, and that date has already come and gone by the time of this article. If you administer a self-hosted Gitea instance, the same clock applies to you in practice, even without a federal mandate.
What changed since our last update
When Gitea 1.27.1 patched this flaw last month, Gitea’s own advisory reported no confirmed exploitation in the wild, and the CVE wasn’t yet on CISA’s KEV list, despite some outlets already claiming active exploitation without solid sourcing. That has changed. The KEV listing is the first official, primary-source confirmation that attackers are using this bug against real Gitea installations.
As a reminder, CVE-2026-60004 lets anyone with ordinary write access to a repository (or any registered user at all, if open registration is enabled) abuse Gitea’s diffpatch API to plant a malicious Git hook and run arbitrary code as the Gitea system user. We won’t re-cover the full changelog here; the 2FA enforcement and ACME certificate fixes that shipped alongside it are in our original article.
What the attack looks like in the wild
Help Net Security reported on August 26 on a specific documented case, based on an account a developer posted on the Russian collaborative tech blog Habr. It’s worth being precise about what this is: one administrator’s own writeup of their own incident, not an officially confirmed mass-exploitation campaign. It’s still a useful, concrete illustration of the exploit chain CISA is now flagging.
According to that account, the organization was running an outdated, self-hosted Gitea instance with open registration and no email confirmation or CAPTCHA in front of it. An automated scanner registered an account, created a repository, and walked through the exploit chain, ending up with code execution as the “git” user inside Gitea’s Docker container.
The attacker’s playbook, per the writeup, moved fast: first a “proof” of RCE committed into a Git branch, then a universal shell-loader, then a cryptocurrency-mining payload. The administrator only found out because their hosting provider flagged abnormally high CPU usage. On the plus side, the container wasn’t running privileged and didn’t survive a restart, so the developer found no evidence of persistence: no cron jobs, no systemd units, no new SSH keys. By their account, the entire active attack phase took roughly 11 seconds.
Afterward, the administrator upgraded to Gitea v1.27.2, disabled open registration, removed extra sign-up methods, rotated all secrets and tokens, tightened the container’s Docker networking, and blocked outbound internet access from the Gitea container entirely.
What to do now
If you run Gitea and haven’t already:
- Upgrade to v1.27.2. This is the single most important step, and it should already be done if you patched when 1.27.1 shipped.
- Disable open user registration, or, if you need it open, require CAPTCHA and email confirmation before an account can do anything.
- If you’ve been running an outdated version with open registration, audit your instance: look for unfamiliar Git branches or hooks, unusual outbound connections, and CPU spikes you can’t explain.
- Rotate secrets and API tokens as a precaution, even without obvious signs of compromise.
- Run Gitea in an unprivileged container and restrict its outbound network access as defense-in-depth. As the Habr account shows, that alone can be the difference between a contained incident and a persistent one.
None of this requires panic. It requires patching, and if you’ve been putting it off, today is better than this weekend. Full details on the original Gitea 1.27.1 patch, including the 2FA and certificate fixes, are in our earlier coverage.