A critical vulnerability in Gitea, identified as CVE-2026-60004, could enable attackers to execute arbitrary shell commands on vulnerable servers. This issue affects Gitea versions 1.17 through 1.27.0 and has been resolved in version 1.27.1.
The flaw resides in Gitea’s diffpatch endpoint, which is responsible for processing repository patches using Git commands. An attacker with standard write access to a repository can exploit this feature to place a malicious Git hook in a temporary bare repository clone.
Because the root of the clone’s repository acts as Git’s directory, a crafted file located at hooks/post-index-change can become an active Git hook.
The attack is initiated by submitting the same specially crafted patch twice. Gitea utilizes the git apply command with index-related options to apply the malicious patch.
Gitea RCE Vulnerability
On Git version 2.32 and later, Git may implement a three-way merge fallback when it detects an add/add collision. During this process, Git checks out the indexed path, even though the operation is executed using the --cached option.
In a bare Git repository, this behavior poses a significant risk because the repository root also serves as the Git directory. A malicious executable file written to hooks/post-index-change is therefore treated as a live hook, not just ordinary repository content.
As a result, Git executes the hook while updating its index, allowing attacker-controlled commands to run as the operating system account that runs the Gitea service.
According to the GitHub Security Advisory (GHSA-rcr6-4jqh-j84m), the vulnerability has a CVSS v3.1 score of 9.8 (Critical), indicating a network attack vector, low attack complexity, no user interaction required, and high impacts on confidentiality, integrity, and availability.
It is classified under CWE-94, which refers to Improper Control of Code Generation, commonly known as code injection. While the exploit requires write access to the repository, this access could be easily obtained on instances with open registration enabled.
An unauthenticated visitor could register for a normal account, create a repository, and use the vulnerable diffpatch route to trigger code execution, leaving publicly accessible Gitea deployments particularly vulnerable.
Successful exploitation could lead to exposure of sensitive Gitea resources, including the app.ini configuration file, application secrets, environment variables, mounted repositories, database credentials, OAuth tokens, and integration credentials.
The ultimate impact of the exploit depends on the permissions assigned to the Gitea service account and the isolation controls around the server.
To exploit the vulnerability, the attacker requires Git version 2.32 or later, an enabled diffpatch route, and a temporary filesystem that permits writing and executing files.
The proof of concept reportedly retrieves command output through Git objects and authenticated Smart HTTP, implying that the attacker may not need an outbound network connection from the target host. Administrators should promptly upgrade Gitea to version 1.27.1.
Until the patch is applied, organizations should disable or restrict access to the diffpatch functionality, turn off public registration, limit repository write permissions, review service account privileges, and monitor Gitea and Git logs for any unusual patch submissions or unexpected hook-related activity.
Recent releases of Gitea have included multiple security fixes, highlighting the importance of prompt upgrades and ongoing exposure management.
