CVE-2026-60004 in Gitea
Summary
by MITRE • 08/26/2026
Gitea before 1.27.1 allows remote code execution via the diffpatch API through Git hook installation.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/26/2026
The vulnerability identified in Gitea versions prior to 1.27.1 represents a critical Remote Code Execution (RCE) flaw rooted in the improper handling of git hooks during repository initialization and patch application processes. This security issue specifically affects the diffpatch API, which is designed to apply patches or diffs to repositories within the platform. The core technical failure lies in how Gitea manages the installation and execution of custom git hooks when processing these incoming changes. Git hooks are scripts that run automatically upon certain events, such as receiving pushed commits or applying a patch. In this context, an attacker can exploit the diffpatch endpoint by crafting malicious patches that include specially crafted hook definitions. When the server processes these patches, it fails to adequately sanitize or restrict the content of the installed hooks, allowing arbitrary code execution on the host system with the privileges of the Gitea service account.
This vulnerability is classified under CWE-94 as Improper Control of Generation of Code (Code Injection). The attack vector leverages the trust relationship between the application and its underlying git infrastructure. By submitting a patch that contains executable scripts disguised as or intended to be installed as post-receive, pre-commit, or other hook types, an attacker can bypass standard input validation mechanisms. Since Gitea operates with specific file system permissions, successful exploitation grants the adversary significant control over the server environment. This is not merely a data exfiltration risk but a complete compromise of the underlying operating system, enabling lateral movement within the network and potential access to sensitive code repositories stored on the same infrastructure.
From an operational perspective, the impact of this vulnerability is severe due to its remote nature and lack of authentication requirements in certain configurations or through compromised credentials if available. An unauthenticated attacker can potentially trigger the RCE by interacting with public repositories that allow patch submissions, depending on the specific Gitea configuration settings regarding repository permissions. Even for authenticated users, the ability to inject code via patches poses a significant threat to internal development workflows and CI/CD pipelines integrated with Gitea. The persistence of such hooks means that even after initial exploitation, an attacker may maintain access through automated hook executions triggered by normal repository activities like pushes or merges.
Mitigation strategies primarily involve immediate upgrading to Gitea version 1.27.1 or later, where the developers have addressed this issue by implementing stricter validation and sanitization of git hooks during patch application. Organizations should also review their current configurations for any custom hook installations that might be vulnerable. Implementing network-level controls such as web application firewalls can provide an additional layer of defense by blocking suspicious patterns associated with code injection attempts in API requests. Furthermore, adher to the principle of least privilege is crucial; ensuring the Gitea service runs under a restricted user account limits the potential damage if exploitation occurs. Regular auditing of installed hooks and monitoring for unusual process executions on the host system can aid in early detection of any attempted or successful exploits aligned with ATT&CK techniques related to command and script interpreter abuse, specifically T1059.