Gitea has fixed a critical remote code execution vulnerability (CVE-2026-60004, CVSS 9.8) that allows a user with write access to a repository to inject an executable Git hook via the diffpatchAPI endpoint and execute arbitrary commands as the Gitea service account. The vulnerability affects all versions from 1.17 up to 1.27.1. A fix is available in version 1.27.1. Public proof-of-concept (PoC) exploit code is already available, although at the time of publication there were no confirmed cases of exploitation in real-world attacks. All administrators of self-hosted Gitea installations must update immediately.
Exploitation mechanism
The vulnerable endpoint POST /api/v1/repos/{owner}/{repo}/diffpatch applies a user-supplied patch inside a shared bare temporary clone of the repository. According to the official Gitea advisory, vulnerable builds invoke git apply with the flags --index, --recount, --cached and --binary. When Git version 2.32 or later is present, the -3 flag (three-way merge fallback) is additionally enabled.
The attack is built on the following chain:
- The attacker submits the same patch twice, creating an add/add conflict.
- The three-way fallback mechanism checks out the indexed path into the working tree despite the use of
--cached. - Because the temporary clone is a bare repository, its root directory coincides with
$GIT_DIR. An executable file placed at the pathhooks/post-index-changelands directly in Git’s hooks directory. - Git automatically runs the
post-index-changehook when the index is updated — the attacker gains arbitrary code execution.
The PoC demonstrates the full attack chain without requiring a reverse connection: the hook stores command output in Git objects, creates a branch with the result, and the attacker retrieves the data via authenticated Smart HTTP.
Exploitation conditions and attack surface
Formally, the endpoint requires authentication and write access to the repository — the route calls reqToken(), which rejects unauthorized requests. However, the Gitea default configuration leaves registration open, does not require email confirmation or manual approval, does not mark new users as restricted, and does not set a limit on repository creation. On an unmodified installation, an external visitor can register on their own, create a repository, and obtain the required write permissions.
The full set of conditions for exploitation:
- Write access to a repository (obtainable via open registration)
- Git version 2.32 or later on the server
- The
diffpatchroute enabled - A writable and executable temporary filesystem
Consequences of compromise
Successful exploitation grants the attacker the privileges of the operating system account under which Gitea runs. According to the advisory, depending on the degree of instance isolation this may lead to disclosure of:
- Application secrets and environment variables
- Mounted repositories
- Database credentials and contents
- OAuth tokens
- Accessible internal services on the network
Given that Gitea is often deployed as a central hub for storing an organization’s source code, compromise of the instance can become an entry point for software supply chain attacks.
Disclosure and patch specifics
The timeline of events deserves separate attention. The fix was merged and backported on July 26, 2026. Version 1.27.1 was released on July 27, and the security advisory was published on July 28. At the same time, in the release notes the fix is listed under MISC as “refactor: git patch apply” rather than under SECURITY. This labeling may cause administrators who only track security fixes to miss a critical update.
The essence of the fix is changing the type of temporary clone from bare to non-bare. A comment in the commit code explicitly warns that Git commands with the --index flag may operate on the working tree. In a non-bare clone, the root directory no longer coincides with $GIT_DIR, breaking the hook injection chain.
The vulnerability was discovered by security researcher Shai Rod (NightRang3r), who is credited as the finder in the Gitea advisory. In addition to the RCE, version 1.27.1 also fixes a file inclusion issue in the Org-mode renderer: #+INCLUDE directives are now returned as plain text instead of reading files from the server filesystem. Gitea has not published a separate advisory or CVE for this issue.
Recommendations
- Immediately update all self-hosted Gitea installations to version 1.27.1. According to Gitea, Gitea Cloud instances are updated automatically.
- Disable open registration as a temporary measure during the update window. This removes the attack path for external unauthenticated users but does not protect against existing users with write access.
- Check the Git version on the server: exploitation requires Git 2.32+. If, for some reason, updating Gitea is not immediately possible, downgrading Git below 2.32 can serve as a temporary workaround (bearing in mind potential side effects).
- Audit logs for suspicious calls to the
/api/v1/repos/{owner}/{repo}/diffpatchendpoint, especially repeated requests with identical patch content. - Review the isolation of the Gitea service account: limit access to secrets, databases, and internal services following the principle of least privilege.
The combination of a 9.8 CVSS score, public PoC, open registration by default, and non-obvious fix labeling in the changelog makes CVE-2026-60004 one of the most dangerous vulnerabilities in the self-hosted Git platform ecosystem in recent times. The only reliable action is to update to Gitea 1.27.1, followed by a review of registration settings and instance isolation. The entry in the NVD confirms the critical severity of the vulnerability.
