CVE-2026-60004, CVSS 9.8, is remote code execution in Gitea — the self-hosted Git service thousands of teams run as a lighter-weight alternative to GitHub or GitLab when they want source control on their own infrastructure. CISA added it to the Known Exploited Vulnerabilities catalogue on 25 August 2026, one day after NVD published it.
What it is
Per NVD, versions of Gitea before 1.27.1 allow remote code execution via the diffpatch API through Git hook installation. Gitea, like every Git server, supports hooks — scripts that run automatically on events like a push or a merge. The diffpatch API path lets this feature be reached in a way that results in a hook being installed and executed that the operator never intended, which is the mechanism by which "review a diff" becomes "run arbitrary code on the server."
Why a source host RCE is a different category of incident than most
Gitea sits in the same structural position as any self-hosted Git platform: it holds an organisation's source code, its CI/CD credentials and integration tokens, its deploy keys, and — through Git hooks specifically, which is the exact feature this CVE abuses — a documented, designed mechanism for executing code as part of normal operation. An attacker who achieves RCE through the hook-installation path is not fighting the platform's security model to get code execution; they are using the platform's actual feature set for a purpose it wasn't meant to serve.
This is the same category of risk this year's KEV additions have repeatedly shown for source hosts and build infrastructure broadly: the systems that assemble and distribute software hold outsized trust relative to how much dedicated security attention they typically receive, because they are treated as internal developer tooling rather than as the production-critical infrastructure they actually are.
Why the one-day gap to KEV matters
NVD published this CVE on 26 August; CISA's catalogue lists it as added the day before, 25 August — evidence that whatever technical detail accompanied disclosure was sufficient for a working exploit to follow almost immediately, or that exploitation was already occurring before the public record caught up. For a self-hosted Git platform, that kind of near-zero gap between disclosure and confirmed exploitation means there was effectively no safe window to patch during before scanning and exploitation attempts against internet-facing instances began.
Self-hosted infrastructure carries a specific version-discipline burden
Teams choose a self-hosted Git platform like Gitea specifically to keep source control under their own operational control rather than depending on a SaaS provider's patch cadence — which is a reasonable choice, but it shifts the entire responsibility for staying current onto whoever administers that instance. A hosted platform patches its users automatically and mostly invisibly; a self-hosted Gitea instance only gets to 1.27.1 if someone actually runs the upgrade. That operational reality is precisely what a near-zero disclosure-to-exploitation gap punishes hardest: SaaS-hosted alternatives were very likely already patched by their provider before this post was written, while self-hosted instances remain exposed for exactly as long as it takes their administrators to notice and act.
What to check this week
Patch to 1.27.1 or later immediately — the near-zero disclosure-to-exploitation gap removes any argument for scheduling this through a normal patch review cycle.
Audit Git hooks installed across every repository the instance hosts, not just the ones your team remembers configuring. If exploitation occurred, a malicious hook may already exist and would continue executing on every subsequent push or merge until found and removed.
Rotate every credential the Gitea instance held, including CI/CD secrets, deploy keys, and integration tokens — the same rule that applies to any source-host compromise applies here: patching stops further exploitation, it does not undo what a credential already exposed can still be used for.
Review recent commits and merges for anything that doesn't match your team's actual activity. A hook-based RCE gives an attacker the same operational position as a legitimate CI process, which is exactly what makes malicious activity through this path easy to miss in a normal review.
How Safeguard helps
Safeguard treats source hosts like Gitea as production infrastructure in its continuous inventory, tracked with the same rigor as the applications they help build — not as internal tooling exempt from the scrutiny applied elsewhere. When a source-host RCE like this one is confirmed exploited within a day of disclosure, that speed is exactly why provenance verification on what a build pipeline produces matters: patching the platform stops new compromise, but only provenance tells you whether anything already shipped was touched before the patch landed.
