Teams that self-host Git usually do it for control: no third party holding the source code, no vendor outage taking down the build pipeline. CVE-2026-60004 is a reminder that self-hosting only delivers that control if the instance itself is locked down as carefully as the systems it was meant to protect.
The bug, in plain terms
CVE-2026-60004 is a code injection vulnerability in Gitea affecting versions 1.17 and later, before 1.27.1. An authenticated user can submit a malicious patch through the diffpatch API endpoint and have it executed as a shell command with the privileges of the Gitea service account. On its own that would already be serious. What makes it worse is what “authenticated” means here in practice.
Why self-registration turns this into an open door
Gitea ships with self-registration enabled by default. An attacker with no prior access at all can register an account, create a repository, and trigger the vulnerability, no stolen credentials, no phishing, no insider needed. CISA has confirmed active exploitation in the wild, including at least one case where a developer’s instance was hit with a cryptocurrency-miner-style dropper delivered through the flaw. The agency added CVE-2026-60004 to its Known Exploited Vulnerabilities catalogue and gave US federal agencies three days to secure their servers.
Who is exposed
Shadowserver counts more than 8,300 internet-facing Gitea instances that remain unpatched. Self-hosted Git is common across European engineering teams that want their source code to stay on infrastructure they control, often for the same data-residency reasons that push organisations toward European cloud providers in the first place. Every one of those instances that still allows public self-registration and runs a version before 1.27.1 is currently reachable by anyone with a browser.
What to do now
Upgrade to Gitea 1.27.1 or later, which fixes the underlying flaw. Separately, and regardless of patch status, review whether public self-registration needs to be enabled at all on an instance holding your source code, most organisations only need it open to invited users. Audit recent account creations and repository activity for anything that does not match your team roster, and check for unexpected processes or outbound connections consistent with a cryptomining payload.
If you run self-hosted Git infrastructure and want it reviewed for exactly this class of exposure, or need help deciding which parts of your DevOps stack are worth self-hosting versus managing through a hardened provider, contact Excello Digital. We help European engineering teams keep the control that self-hosting promises without inheriting the attack surface that comes with it.