Gitea diffpatch RCE: Repeated Patch Submission Installs a Malicious Git Hook (CVE-2026-60004)

What happened

A GitHub Security Advisory (GHSA-rcr6-4jqh-j84m, CVE-2026-60004, CVSS 9.8) discloses a remote code execution flaw in Gitea's diffpatch endpoint, with a public proof-of-concept. According to the advisory, services/repository/files/patch.go applies attacker-controlled patches inside a shared bare temporary clone using git apply --index --cached. Submitting the same patch twice triggers an add/add collision, causing Git's three-way-merge fallback to check the indexed path out to disk even under --cached. Because the working directory in a bare clone is the repository's $GIT_DIR, a patch that adds an executable file named hooks/post-index-change becomes a live Git hook. Git then invokes that hook while writing the index, executing attacker-supplied shell commands as the Gitea service account. The PoC avoids any outbound network requirement by writing command output into Git objects and exfiltrating it via a pushed branch, fetched back over authenticated smart HTTP.

Per the advisory, exploitation requires only ordinary write access to a repository — meaning any authenticated user who can create a repo. With open self-registration enabled (Gitea's default), the advisory states an unauthenticated visitor can register an account and reach the same attack path.

Why it matters

This is CWE-94 command execution as the Gitea OS user, not a privilege-escalation edge case — the bar to trigger it is a normal write-access account, which many Gitea instances hand out to anyone who signs up. The advisory notes that, depending on host isolation, a successful exploit could expose app.ini and application secrets, process-environment secrets, mounted repository data, database credentials, and OAuth/integration tokens — potentially providing a foothold into adjacent internal or externally reachable services. Any self-hosted Gitea instance with the diffpatch route enabled, Git 2.32+, and a writable/executable temp filesystem meets the advisory's stated preconditions.

What defenders should do now

• Identify all Gitea instances in your environment and check whether open registration is enabled — if it is and isn't required, disable it to remove the no-credential attack path.
• Watch for repeated/duplicate diffpatch API submissions against the same repository in a short window, and for newly added files under a hooks/ path in patch content, as both are described in the advisory as core to triggering the bug.
• Hunt for unexpected branches or commits created without a corresponding user-facing push event, and for anomalous outbound Git fetches immediately following patch submissions — consistent with the PoC's exfiltration-via-branch technique.
• Review process execution and file-integrity logging on Gitea hosts for shell activity spawned by the Gitea service account that doesn't correspond to normal application behavior.
• Restrict filesystem permissions on Gitea's temp directory where feasible (non-executable temp mounts would break the hook-invocation step), and isolate the Gitea service account's access to secrets and adjacent systems as a defense-in-depth measure.
• Track vendor guidance for a patched Gitea release and apply it once available; until then, treat repository write access as equivalent to code-execution access on the host.

Developing intel

This is net-new intelligence with a public PoC and no confirmed patch referenced in the source at time of writing. Details may evolve as the vendor responds — consult the original advisory for authoritative, up-to-date information: GHSA-rcr6-4jqh-j84m.