CVE-2026-60004 — a remote code execution bug in Gitea rated 9.8 by CVSS — allows an ordinary repository writer to plant a Git hook and run shell commands as the Gitea service account.
The exploit technique: add/add collision, three-way fallback, and a bare temporary clone
The vulnerability lives in the POST /api/v1/repos/{{owner}}/{{repo}}/diffpatch endpoint. According to Gitea's security advisory, the endpoint applies a supplied patch inside a shared bare temporary clone and invokes git apply with the flags --index, --recount, --cached, and --binary, and it adds the -3 three-way fallback option when the server runs Git 2.32 or later. An attacker submits the same patch twice to create an add/add collision. The three-way fallback then checks the indexed path out even though the operation uses --cached. Because the temporary clone is bare, its root is $GIT_DIR, so an executable file placed at hooks/post-index-change lands in Git's hook directory and becomes active. Git runs that hook while updating the index, enabling arbitrary shell execution under the Gitea operating-system account.
Who can exploit it and how an outsider could reach write access
Exploitation requires authentication and repository write permission, an enabled diffpatch route, Git 2.32 or later on the server, and a writable, executable temporary filesystem. However, Gitea's default configuration enables open registration: it "leaves registration open, requires neither email nor manual approval, does not mark new users as restricted, and imposes no default repository-creation limit." That means a visitor to an unchanged installation can create a normal account, initialize a repository, and obtain the repository write access needed to run the attack path without any pre-existing credentials.
Proof‑of‑concept behavior and exploitation constraints
Gitea's advisory includes public proof-of-concept (PoC) code. The PoC signs in with a normal account, creates an initialized private repository, sends the malicious patch twice, and retrieves the command output. The exploit needs no outbound callback: the hook can store its output in Git objects, create a branch containing the result, and allow the attacker to fetch it over authenticated smart HTTP. The advisory does not state whether the flaw has been observed in the wild, and as of July 29, 2026 none of the cited primary sources reports whether exploitation occurred before or after the fix became available.
Fix, timeline, and deployment notes
The remedy is an upgrade to Gitea 1.27.1. The root change is small but significant: Gitea changed the temporary clone from bare to non-bare so Git commands that use --index will operate on the working tree rather than $GIT_DIR. That change was merged and backported on July 26, 2026. Version 1.27.1 shipped on July 27, and Gitea published the security advisory on July 28. The release notes list the code change under MISC as "refactor: git patch apply" rather than under a security heading. Gitea said on July 27 that Gitea Cloud instances would be upgraded automatically. Disabling open registration can remove the public account-creation path while the update is deployed, but it neither fixes the underlying flaw nor protects installations from already-existing users who have repository write access.
What this means for technologists, affected enterprises, and end users
- Technologists and security teams: upgrade to 1.27.1 promptly; if an immediate upgrade is not possible, look for whether the diffpatch route is enabled, whether the instance runs Git 2.32 or later, and whether the temporary filesystem used by diffpatch is writable and executable—those are the conditions the advisory cites as necessary for exploitation.
- Affected enterprises and procurement leaders: note that default installations allow outsider account creation and repository creation, creating an accessible path to exploit unless registration policies have been hardened. The advisory highlights that successful exploitation yields the privileges of the Gitea operating-system account and could expose application and environment secrets, mounted repositories, database credentials and contents, OAuth credentials, and reachable internal services.
- End users and administrators of hosted instances: Gitea Cloud will be upgraded automatically, Gitea said, but self-hosted instances must be updated to 1.27.1. Disabling open registration can reduce immediate exposure from newly created outsider accounts but does not remove risk from existing write-capable users.
Small implementation details—how a temporary clone is created, which Git options are passed, and whether registration is left open by default—made this bug both powerful and easy to reach on unmodified deployments. As of the end of July 2026, the public record confirms a high-severity RCE with a working PoC and a quick upstream fix; it does not yet say whether the vulnerability was exploited before or after the patch was released.
