Gitea Remote Code Execution via diffpatch Git Hook Installation (CVE-2026-60004) — Threadlinqs Intelligence
As of 2026-07-29, Gitea Remote Code Execution via diffpatch Git Hook Installation (CVE-2026-60004) is a critical-severity vulnerability threat, tracked by Threadlinqs Intelligence with 9 detection rules (Splunk SPL, Microsoft KQL, Sigma) and 20 indicators of compromise.
Threat ID: TL-2026-1767 · Severity: CRITICAL · CVSS: 9.8 · Status: ACTIVE · Category: VULNERABILITY
A Gitea user with only ordinary repository-write access can abuse the diffpatch API endpoint to plant a malicious hooks/post-index-change Git hook via an add/add patch collision, achieving arbitrary
CVE-2026-60004 (GHSA-rcr6-4jqh-j84m) is a critical remote code execution vulnerability in Gitea's diffpatch functionality, implemented in services/repository/files/patch.go and exposed via the POST /api/v1/repos/{owner}/{repo}/diffpatch API endpoint. The endpoint applies an attacker-supplied patch inside a shared bare temporary repository. When the same patch is submitted twice, Git's three-way merge fallback (active on Git 2.32 and newer) checks out the colliding add/add path to the filesystem despite the request using the --cached flag. Because the temporary repository is a bare repository, its root directory is equal to $GIT_DIR, so the checked-out path can land inside hooks/. By naming the colliding path hooks/post-index-change and making it executable, the attacker installs a live Git hook that Git automatically invokes the next time the index is updated, running attacker-chosen shell commands with the privileges of the Gitea operating-system service account.
The public proof-of-concept (gitea_diffpatch_rce_poc.py) demonstrates the full chain: authenticate to the target Gitea instance (existing or newly self-registered account), initialize a repository, submit the crafted patch twice to trigger the hook installation, and then retrieve command output without any outbound network callback — the hook writes the output into Git objects, creates a branch containing the result, and the attacker fetches it back over authenticated Git smart HTTP. This makes the exploit fully self-contained within Gitea's own legitimate protocol traffic, complicating network-based detection.
The vulnerability's practical severity is amplified by Gitea's default configuration: self-registration is enabled out of the box, with no email verification, no manual approval step, and no default restriction on new accounts or repository creation. This collapses the nominal "requires repository write access" prerequisite into "requires only network access to the login page" on any unmodified installation, making the flaw effectively unauthenticated pre-exploitation. Exploitation additionally requires Git 2.32 or later on the server and a writable, executable temporary filesystem, both common on default installs.
Successful exploitation grants OS-level command execution as the Gitea service account, which on a typical deployment can expose application secrets in app.ini (JWT/OAuth signing keys, mailer and storage credentials), process environment variables, the underlying SQLite/MySQL/PostgreSQL database (issues, private repositories, session tokens, 2FA secrets, OAuth application secrets), and any reachable internal services depending on network isolation of the host.
The same researcher, Shai Rod (NightRang3r), concurrently reported a related but separately-tracked file-inclusion weakness in Gitea's Org-mode renderer: a crafted #+INCLUDE directive could cause the server to read and return arbitrary filesystem paths (demonstrated against /etc/passwd on a Gitea 1.27.0 host). Gitea did not assign a separate CVE for this issue but fixed it in the same 1.27.1 release by making #+INCLUDE paths render as plain text instead of being read from the server filesystem.
Gitea shipped the fix on 2026-07-26 (merged and backported), released as version 1.27.1 on 2026-07-27 (with Gitea Cloud auto-upgraded), and published the GHSA-rcr6-4jqh-j84m advisory on 2026-07-28 crediting NightRang3r. As of 2026-07-29 there is no confirmed in-the-wild exploitation, but the combination of a CVSS 9.8 score, public working PoC, a widely self-hosted DevOps platform, and a default configuration that removes the authentication barrier makes rapid patching a priority. This also lands amid a broader run of critical Gitea disclosures in July 2026, including CVE-2026-58443 (public-only repository tokens able to update private PR head branches and trigger private Actions workflows, fixed in 1.27.0), underscoring an active period of scrutiny on Gitea's API authorization model.
Target sectors: technology, softwaredevelopment, government administration, financialservices, managedserviceproviders, education
Target regions: Global
Detections & IOCs
As of 2026-07-30, this threat has 9 detection rule(s) across Splunk SPL, Microsoft KQL and Sigma, and 20 indicator(s) of compromise. Detection query text and full IOC values are available to authenticated users and programmatically via the Threadlinqs MCP server (Purple tier). View plans.
VULNERABILITY, CRITICAL, threat intelligence, cybersecurity, CVE-2026-60004, T1595, T1588, T1587, T1190, T1136, T1059, T1546, T1068, T1564, T1552