Gitea CVE-2026-60004 is a critical remote code execution flaw (CVSS 9.8) that CISA added to its Known Exploited Vulnerabilities catalog on August 25, 2026 after evidence of active exploitation. The bug lets an attacker with ordinary repository write access abuse Gitea's diffpatch API endpoint to plant an executable Git hook and run shell commands as the Gitea service account. Because Gitea ships with open registration on by default, an unauthenticated visitor can simply register, create a repository, and gain the write access the exploit needs. It affects every Gitea release from version 1.17 onward and is fixed in version 1.27.1.

The self-hosted Git service is a common backbone for internal source code, CI pipelines, and release artifacts, which makes a service-account shell an unusually high-value foothold. Security researcher Shai Rod (NightRang3r) is credited with reporting the issue, first disclosed in a Gitea advisory last month. CISA has not published indicators or attribution, but a developer writing on the Russian platform Habr documented their own Gitea instance being hit with CVE-2026-60004 to drop a cryptocurrency-miner-style payload. The intrusion surfaced only when their hosting provider, HOSTKEY, throttled the server for sustained CPU use above 70 percent, a reminder that the first sign of code execution is often a billing alert rather than a security one.

Which Gitea versions are affected and how do I fix it?

Every Gitea build from 1.17 up to the patched release is vulnerable, and the fix is to upgrade to 1.27.1. Where an immediate upgrade is not possible, the practical stopgap is to close the unauthenticated path into repository write access. The developer whose instance was compromised traced the exposure to a permissive registration configuration, and disabling open sign-up removes the "register your way to write access" shortcut the attackers relied on.

Why does open registration turn this into an unauthenticated bug?

On paper the vulnerable API call requires authentication and write permission, which sounds like a limited, insider-only risk. In practice Gitea's default DISABLE_REGISTRATION = false lets anyone create an account, and a fresh account can create its own repository and immediately hold write access to it. That collapses the distance between "internet visitor" and "code execution on your server" to a few HTTP requests. Instances that also leave REQUIRE_SIGNIN_VIEW = false and ENABLE_OPENID_SIGNUP = true widen the exposure further.

Our read

CISA gave this a three-day remediation deadline for a reason: a self-hosted developer platform is exactly the kind of internal system defenders assume is shielded, right up until an attacker registers an account through it. This is where continuous verification earns its place. Point-in-time testing would very likely miss a bug that only became a KEV entry after real-world abuse, and our own analysis of 2025 found that 67 percent of the year's actively exploited vulnerabilities would have been missed by a single annual pentest, with a median gap of just 26 days between disclosure and exploitation. The defensible posture is to treat every internet-reachable dev tool as attack surface, verify its exposure continuously, and confirm the 1.27.1 patch actually took rather than assuming the upgrade closed the door.

Reporting by The Hacker News and SecurityWeek; CVSS and affected-version detail per the Gitea advisory, exploitation status per CISA KEV. Sources linked above.

Related: How EPSS and KEV miss fresh exploitation and Nexus Void continuous verification.