
CISA has added CVE‑2026‑60004 to its Known Exploited Vulnerabilities catalogue after confirming that the flaw in Gitea is being actively exploited in the wild, as noted in the agency’s advisory. The vulnerability permits an authenticated user who already possesses write permissions on a repository to execute arbitrary commands on the server that hosts the self‑hosted Git service.
Security researchers tracking the issue have assigned it a CVSS score of 9.8, indicating a high likelihood of full system compromise if exploited, as detailed in a report by securityonline.info. The flaw resides in the diffpatch API endpoint and affects Gitea releases from version 1.17 up to, but not including, 1.27.1, provided that Git version 2.32 or newer is present and the diffpatch feature is enabled.
An attacker who can push a repository branch creates a malicious patch that, when processed by the diffpatch API, writes an executable script into the repository’s .git/hooks directory, as outlined in the GitHub security advisory. When the hook is subsequently triggered by a normal Git operation, the script runs under the privileges of the Gitea service account, granting the attacker full shell access to the underlying host.
No specific threat‑actor group has been publicly linked to the exploitation attempts, but the presence of CVE‑2026‑60004 in the KEV catalogue confirms that the vulnerability is being used in real‑world attacks against exposed Gitea instances. Organisations that depend on self‑hosted Git for internal development, continuous integration, or collaborative workflows are therefore facing a direct risk to their source‑control infrastructure. Until the flaw is remedied, any publicly reachable Gitea deployment should be regarded as a potential entry point for adversaries seeking to pivot within the network.
The incident underscores the danger of granting authenticated users overly broad repository rights, particularly when internal APIs such as diffpatch are exposed without additional validation or request sanitisation. It also demonstrates how a seemingly modest code‑injection vector can be chained with legitimate Git functionality to achieve remote code execution on the host. Organisations should therefore reassess API exposure, enforce the principle of least privilege on service accounts, and consider disabling unnecessary endpoints in internal tooling.
Defenders are advised to upgrade Gitea to version 1.27.1 or later, which patches the faulty diffpath handling and eliminates the ability to write malicious hooks through the API. When an immediate upgrade is not feasible, administrators can disable the diffpatch endpoint via configuration or strictly limit repository write permissions to a minimal set of trusted accounts. In parallel, applying the latest security patches to the host operating system and hardening the container or virtual machine where Gitea runs will reduce the overall attack surface and limit post‑exploitation mobility.
In addition, monitoring the hooks directory for newly created or altered files provides an early warning sign of malicious activity. Reviewing service‑account logs for unexpected command execution and enforcing least‑privilege policies for the Gitea process will help detect and contain any successful exploit before it can cause further damage.