Active Exploitation of Gitea CVE-2026-60004 Confirmed by CISA

CISA on August 25, 2026 confirmed active exploitation of the critical vulnerability CVE-2026-60004 in the Git repository management platform Gitea and added it to the Known Exploited Vulnerabilities (KEV) catalog. The vulnerability, with a CVSS score of 9.8, allows an attacker with write permissions to a repository to execute arbitrary commands on the server as the Gitea system account. What makes it particularly dangerous is that Gitea’s default configuration allows open registration, meaning the attacker does not need pre‑obtained credentials — it is enough to register an account and create their own repository. U.S. federal agencies are required to remediate the vulnerability by August 28, 2026. All Gitea administrators are advised to immediately update to version 1.27.1 or later.

Exploitation mechanism

The vulnerability affects the diffpatch API endpoint, which is intended for working with patches. An attacker sends a specially crafted malicious patch to this endpoint, which makes it possible to inject an executable Git hook from content controlled by the repository. After the hook is installed, the attacker can execute arbitrary shell commands as the Gitea service account at the operating system level.

Formally, calling the vulnerable API requires authentication and write permissions to the repository. However, the exploitation chain becomes trivial on instances with the default configuration:

• The attacker registers a new account (open registration is enabled by default)
• They create their own repository, automatically obtaining write permissions in it
• They send a malicious patch to the diffpatch endpoint
• The injected Git hook executes arbitrary code on the server

According to available information, all Gitea versions starting from 1.17 are affected. The fix has been released in version 1.27.1. Discovery of the vulnerability is attributed to a security researcher known under the pseudonym NightRang3r.

Dangerous default configuration

The key factor that turns this vulnerability from privilege‑dependent into effectively unauthenticated is the set of configuration parameters that, by default, create an open environment in Gitea. According to the official Gitea documentation, the following parameters in the [service] section are critical:

• DISABLE_REGISTRATION = false — registration of new users is allowed
• REGISTER_EMAIL_CONFIRM = false — email confirmation is not required
• ENABLE_OPENID_SIGNUP = true — registration via OpenID is allowed
• REQUIRE_SIGNIN_VIEW = false — viewing pages and using the API do not require authorization

This combination means that any external user can, without any restrictions, create an account, obtain a repository with write permissions, and exploit the vulnerability. The attack vector works over HTTPS, so the absence of open SSH access to Gitea does not provide protection.

Indicators of exploitation

CISA has not disclosed details about specific exploitation incidents or indicated which groups are behind the attacks. Nevertheless, inclusion of the vulnerability in the KEV catalog means that the agency has reliable evidence of active exploitation.

Independently of this, a post was published on the Habr platform by a developer who described the compromise of their own Gitea instance via CVE-2026-60004. However, this information is based on a single unverified source and has not been confirmed by independent researchers or the vendor, so the details of the described incident should be treated with caution.

Impact assessment

Gitea is a popular self‑hosted platform for managing Git repositories, widely used by small and medium development teams, educational institutions, and open source projects. The scale of the potential impact is determined by several factors:

• Wide range of vulnerable versions — all versions starting from 1.17 are affected, which covers a significant portion of existing installations
• Low barrier to entry for the attacker — exploitation does not require prior access under the standard configuration
• Severity of consequences — code execution at the OS level opens the way to full server compromise, source code theft, insertion of malicious backdoors into repositories, and lateral movement across the infrastructure
• Risk of supply chain attacks — compromise of the code management server can lead to malicious code being embedded in built artifacts

Mitigation recommendations

The response priority is maximum. Recommended actions:

1. Update Gitea to version 1.27.1 or newer. This is the only complete way to eliminate the vulnerability.
2. If immediate updating is impossible, apply the following temporary measures:
   • Set DISABLE_REGISTRATION = true to block new user registrations
   • Set REQUIRE_SIGNIN_VIEW = true to restrict access to the API
   • Disable ENABLE_OPENID_SIGNUP
   • Enable REGISTER_EMAIL_CONFIRM
3. Conduct an audit of recently registered accounts and created repositories for signs of suspicious activity.
4. Check for unusual Git hooks in repositories, especially those containing executable scripts.
5. Monitor CPU load — abnormal resource consumption may indicate deployed malicious code.
6. Restrict network access to the Gitea instance using a firewall if the platform is not intended for public use.

Given CISA’s confirmed active exploitation and the CVSS score of 9.8, updating Gitea to version 1.27.1 should be carried out within hours, not days. For instances where updating is delayed, disabling open registration is a minimally necessary measure that breaks the most accessible exploitation chain but does not eliminate the vulnerability itself for users who already have write access.