A critical vulnerability in Gitea, the open-source Git hosting and software development platform, is being actively exploited, with the U.S. Cybersecurity and Infrastructure Security Agency (CISA) adding the flaw to its Known Exploited Vulnerabilities catalog. Tracked as CVE-2026-60004, the vulnerability can allow attackers to execute shell commands on affected Gitea servers.
Gitea rates the vulnerability as critical with a CVSS score of 9.8. The flaw affects Gitea versions from 1.17 through 1.27.0 and was fixed in Gitea 1.27.1, released on July 27, 2026. Administrators are advised to move to a current supported release rather than remain on an affected version. The vendor’s official security advisory provides the technical details and mitigation guidance.
The vulnerability is located in Gitea’s diffpatch API. Exploitation depends on repository write access, but Gitea says an external visitor can potentially obtain that access by registering an account and creating a repository when open registration is enabled. This can make the attack path accessible to an unauthenticated visitor before the vulnerable operation is performed.
The attack involves specially crafted patches and Git’s handling of conflicts during a three-way merge. According to Gitea, a repeated specially constructed patch can cause Git to materialize an indexed file inside a temporary bare repository. Because the repository’s root also serves as its Git directory, the process can be used to place an executable Git hook in the repository’s hooks directory. When the relevant Git operation runs, the hook can execute shell commands as the Gitea operating-system account.
The vendor identifies post-index-change as the Git hook used in the documented proof of concept. Gitea also notes that the described exploitation path requires Git 2.32 or later, along with other environmental conditions. These details mean the attack path is not identical across every installation, but vulnerable internet-facing deployments remain exposed to the underlying flaw.
Public exploitation followed the release of the patch and technical details. Gitea’s advisory includes a proof of concept demonstrating the issue, while independent security researchers have published additional technical analysis and detection material.
There is also evidence of exploitation against a real Gitea installation. In an incident report published on Habr, a developer described a compromise that began after their hosting provider warned about sustained CPU usage above 70 percent. The investigation identified an automated attack chain involving account registration, repository creation, exploitation of the vulnerable functionality and execution of a malicious payload. The reported exploitation sequence took about 11 seconds.
According to the incident report, the attacker subsequently downloaded a shell loader and a miner-like payload that consumed CPU resources. The affected Gitea deployment was running inside a Docker container. The developer reported that the container was not privileged and that the malicious process did not persist outside the container after the container was restarted. The investigation also found no persistence through cron, systemd or new SSH keys.
The documented incident demonstrates exploitation of the vulnerability in the wild, but it does not establish that cryptocurrency mining is the objective of every attack. The attacker or group responsible for the broader exploitation activity has not been publicly identified in the information reviewed for this report.
CISA added CVE-2026-60004 to its Known Exploited Vulnerabilities catalog on August 25, 2026. The catalog identifies the issue as a Gitea code-injection vulnerability and describes how an attacker with repository write access can send a malicious patch to the diffpatch API, place an executable Git hook and execute shell commands as the Gitea service account. CISA’s federal civilian agency remediation deadline is August 28, 2026. The catalog does not identify known ransomware use for the vulnerability.
The current CVE record also reflects the seriousness of the issue. The vulnerability has a CVSS 3.1 score of 9.8 and is described as having a network attack vector, low attack complexity, no required privileges in the CVSS vector, no user interaction and high impact on confidentiality, integrity and availability. The record is still undergoing analysis. The CVE/NVD entry also records CISA’s assessment that exploitation is active, automatable and has total technical impact.
Gitea released version 1.27.2 on August 14, 2026, after the release containing the CVE fix. As a result, organizations should not treat 1.27.1 as the endpoint for maintenance and should instead use a current supported version.
The potential consequences extend beyond command execution itself. Gitea warns that a compromised service account may expose configuration files such as app.ini, application secrets, environment variables, repository data, database credentials, database contents and OAuth or integration credentials, depending on how the installation is configured.
Security researchers and vulnerability tracking services have also reported thousands of Gitea instances exposed to the internet. Current reporting citing Shadowserver places the number of observed exposed instances at nearly 5,000. That figure represents systems observed online, not a confirmed count of vulnerable or compromised installations.
Organizations running Gitea should verify their versions, upgrade affected installations, review whether public registration is enabled and investigate unexpected accounts, repositories, Git hooks, processes and outbound connections. Where compromise is suspected, administrators should also assess whether credentials and secrets accessible to the Gitea service have been exposed and rotate them as necessary.
CVE-2026-60004 has therefore moved beyond a newly disclosed software vulnerability into an active security incident involving real-world exploitation, public proof-of-concept material and inclusion in CISA’s federal vulnerability catalog. The clearest immediate defensive measure is to remove vulnerable Gitea versions from production and investigate exposed systems for signs of unauthorized activity.
Discover more from Aree Blog
Subscribe now to keep reading and get access to the full archive.
