More than 8,300 internet-exposed Gitea instances remain unpatched against a critical remote code execution flaw that attackers are actively exploiting, according to Shadowserver Foundation scans. The watchdog counted 8,393 vulnerable IP addresses on August 27, more than a month after a fix shipped.
The bug, tracked as CVE-2026-60004, carries a CVSS score of 9.8 and is classified as improper control of code generation (CWE-94). Salesforce security researcher Shai Rod reported it, and Gitea patched it in version 1.27.1 on July 27. A fix has been available for over a month. The exposure count says how that went.
How the exploit works
The attack path runs through Gitea’s diffpatch API endpoint. Any user with write access to a repository can submit a malicious patch, and the merge process collides with Git hook handling in a way that lets the attacker plant a hook. Git hooks are shell scripts that run automatically on events like pushes and merges, so the planted hook executes arbitrary commands with the privileges of the Gitea service account.
Write access sounds like a meaningful barrier. It is not, because Gitea’s default configuration allows open registration. Gitea’s own advisory points out that an unauthenticated visitor can register an account, create a repository, and thereby obtain the write access the exploit needs. On a default instance, the practical requirement for full RCE is a web browser and a spare email address.
The CVSS vector confirms it: network reachable, low complexity, no privileges required, no user interaction. Reports of in-the-wild attacks describe cryptocurrency mining payloads deployed against unpatched servers, but mining is just the monetization someone bothered to document. Command execution as the service account also means access to everything the Gitea process can reach.
CISA moved in three days
On August 25, CISA added CVE-2026-60004 to its Known Exploited Vulnerabilities catalog and gave US federal civilian agencies until August 28 to patch, a three-day deadline under Binding Operational Directive 26-04. The agency’s warning was blunt: this type of vulnerability is a frequent attack vector for malicious cyber actors and poses significant risks to the federal enterprise.
Three days from KEV listing to deadline is aggressive by BOD standards and reflects how trivially the flaw converts from authenticated to unauthenticated access on default configurations.
Gitea’s rough year
This is the third significant Gitea vulnerability of 2026. In May, CVE-2026-27771 exposed private container registries through a missing authorization check on the registry pull endpoint, scoring 8.2 and leaking images and credentials without authentication. In July, attackers were abusing CVE-2026-20896, an authentication bypass in the official Gitea Docker image affecting instances running reverse proxy authentication headers. The pattern across all three is the same: Gitea is a self-hosted GitHub alternative with more than 400,000 installations, and the deployments are widely exposed to the internet while being maintained far less diligently than the SaaS platforms they replace.
What to do, in order
If you run Gitea, work through this list before anything else today:
- Check your version. Anything from 1.17 through 1.27.0 is affected. Upgrade to 1.27.1 or later, and review the release notes for subsequent security releases, because more Gitea CVEs have landed since.
- Disable open registration unless you genuinely run a public community instance. This single setting is what converts the bug from “requires a malicious insider” to “requires a web browser.”
- Review existing repositories for unexpected Git hooks and unfamiliar accounts created around the exploit window.
- Check service logs for odd patch submissions against the diffpatch endpoint, and inspect running processes for anything mining-shaped.
- If you find evidence of command execution, rotate the credentials the Gitea service account could reach: CI/CD tokens, deployment keys, integrated secrets. Assume repository integrity is compromised and verify.
Keep the scan numbers in perspective. Shadowserver counts 8,393 internet-visible vulnerable instances; servers behind firewalls and VPNs do not appear in that count, so the real total is unknown and could be either direction. Internet exposure is not a prerequisite for harm either, since an internal Gitea server sits inside the development network with access to deployment infrastructure, which is often a better prize than anything on the public internet.
The uncomfortable takeaway is the gap between disclosure and patching. Gitea fixed this on July 27. CISA confirmed active exploitation on August 25. Nearly three weeks of free exploitation time produced a five-figure cleanup bill that administrators are now working through, and every one of those 8,393 servers had a one-command fix available the entire time.
If you cannot patch today
Some operators cannot bounce a Gitea server on a weekday, and that is a defensible position only if you compensate in the meantime. The exploit enters through the diffpatch API, so blocking or rate-limiting requests to paths matching /api/v1/repos/*/diffpatch at your reverse proxy cuts the attack path off entirely while you arrange a maintenance window. Disabling new registrations closes the unauthenticated path even on an unpatched build, though it does nothing about existing accounts with write access, which is why the hook and account review still needs to happen regardless of when you patch. Locking down network exposure is the third lever: most Gitea instances have no business being reachable from the open internet, and moving them behind a VPN or an IP allowlist removes them from the population that automated scanners and miners are sweeping. None of these substitutes for the upgrade, but any one of them takes your server out of the 8,393 that the next scan will count.