CVE-2026-60004: Gitea — diffpatch Git Hook Code Injection

Background

Gitea is a lightweight, self-hosted Git service used widely by organisations that want GitHub-style code hosting without depending on a third-party platform. It exposes both a web UI and a full REST API, including endpoints used to generate and apply patches between commits, a common building block for pull request diffing and code review tooling.

Gitea versions 1.17 through 1.27.0 contain a critical code injection vulnerability, CVE-2026-60004, in the diffpatch API endpoint. Reported by researcher NightRang3r and disclosed by the Gitea project on July 28, 2026 as GHSA-rcr6-4jqh-j84m, the flaw carries a CVSS v3.1 score of 9.8 and is classified under CWE-94, Improper Control of Generation of Code. CISA added CVE-2026-60004 to its Known Exploited Vulnerabilities catalog on August 25, 2026, with a mandatory remediation deadline of August 28, three days later, reflecting confirmed active exploitation.

Technical Mechanism

The vulnerable endpoint is POST /api/v1/repos/{owner}/{repo}/diffpatch, which accepts a patch and applies it to a repository. The exploitation path abuses a specific interaction between Git’s merge fallback logic and how Gitea handles patch application internally.

Submitting the same patch twice against the endpoint produces an add/add collision: both patch applications attempt to create the same file path. When Git resolves that collision, it falls back to a three-way merge. That fallback checks the indexed path out to disk, even though the operation was invoked with the --cached flag, which is supposed to restrict Git to index-only operations without touching the working tree.

Gitea applies patches inside a temporary bare clone of the repository. In a bare repository, the repository root itself functions as $GIT_DIR. That detail is what turns a working-tree write into a hook installation: if the attacker’s patch places an executable file at hooks/post-index-change, and the collision fallback writes it to disk inside that bare clone, the file lands directly inside Git’s hook directory rather than a normal working-tree location.

From there, no separate trigger is required. Git invokes post-index-change automatically whenever the index is written, which happens routinely during normal repository operations. The hook script executes with the privileges of the Gitea service process, giving the attacker arbitrary shell command execution on the host.

Exploitation requires Git 2.32 or newer on the server (the version where the relevant merge fallback behaviour is present), the diffpatch route enabled, and a writable, executable temporary filesystem, conditions met by the overwhelming majority of default Gitea deployments.

Real-World Exploitation Evidence

The July 28 advisory did not claim in-the-wild exploitation at the time of disclosure, but it shipped alongside public proof-of-concept code, and additional PoC implementations (including one published to GitHub under 0xBlackash/CVE-2026-60004) have circulated since. CISA’s decision to add the CVE to the KEV catalog on August 25, with a compressed three-day remediation window, is itself the strongest available signal of confirmed active exploitation: KEV inclusion requires evidence of exploitation in the wild under CISA’s own criteria, and short deadlines are reserved for vulnerabilities the agency considers under immediate attack.

No named threat actor or campaign has been publicly attributed to CVE-2026-60004 as of this writing. What makes it attractive for opportunistic scanning is the low bar to reach “write access.” The vulnerability does not require pre-existing elevated privileges, only ordinary repository write access, and on any Gitea instance running with default open self-registration, an anonymous visitor can create an account, spin up a repository, and satisfy that requirement entirely on their own. Effectively, that converts a “requires authentication” bug into something close to unauthenticated remote code execution on unmodified installations, which is consistent with how some vendors in the space have informally described this class of finding.

Impact Assessment

Successful exploitation gives an attacker arbitrary shell command execution as the Gitea service account on the host. From there, the practical impact includes:

• Full read and write access to every repository hosted on the instance, including private source code, CI/CD configuration, and any secrets committed or referenced in build pipelines
• Theft of API tokens, SSH deploy keys, and webhook secrets stored in the Gitea configuration or database
• Modification of repository content, including the ability to backdoor source code that downstream CI/CD pipelines will subsequently build and deploy
• Lateral movement from the Gitea host into connected infrastructure, particularly build runners, package registries, and any systems the Gitea service account can reach over the network
• Persistence via additional planted hooks or scheduled tasks surviving beyond the initial exploitation

Because Gitea instances frequently sit at the centre of an organisation’s software supply chain, feeding artifacts directly into CI/CD and deployment pipelines, compromise here has outsized downstream risk compared to a typical single-host RCE.

Affected Versions

Remediation Steps

1. Upgrade immediately: Update Gitea to version 1.27.1 or later. The fix corrects the patch-application logic so hook-directory paths cannot be written via the diffpatch collision path.

2. Disable open self-registration: If upgrading cannot happen immediately, disable open user registration (DISABLE_REGISTRATION = true in app.ini) to remove the trivial path to obtaining the write access this vulnerability requires.

3. Restrict or disable diffpatch API access: Where feasible, front the API with a reverse proxy rule blocking external access to /api/v1/repos/*/diffpatch until the upgrade is applied.

4. Audit existing repositories for planted hooks: Check every repository’s bare clone directory on disk for unexpected files under hooks/, particularly hooks/post-index-change, that do not correspond to legitimate server-side hook configuration.

5. Rotate credentials: Treat any Gitea instance that was internet-accessible and unpatched between July 28 and the upgrade date as potentially compromised. Rotate API tokens, deploy keys, webhook secrets, and any credentials the Gitea service account had access to.

6. Review CI/CD pipeline integrity: If Gitea feeds build or deployment pipelines, audit recent pipeline runs and build artifacts for signs of tampering introduced through backdoored source.

Detection Guidance

Filesystem indicators:

Search Gitea’s repository storage path for unexpected executable files inside bare repository hook directories:

find /path/to/gitea-repositories -path "*/hooks/post-index-change" -newer /path/to/known-good-timestamp

Any hooks/post-index-change file that isn’t part of a legitimate server-side hook deployment should be treated as evidence of exploitation.

Application log indicators:

Review Gitea’s access logs for repeated identical POST requests to the diffpatch endpoint from the same source in quick succession, the double-submission pattern the exploit relies on:

POST /api/v1/repos/{owner}/{repo}/diffpatch HTTP/1.1
POST /api/v1/repos/{owner}/{repo}/diffpatch HTTP/1.1

Process-level indicators:

Monitor for unexpected child processes spawned from the Gitea service process, particularly shell invocations, outbound network connections, or file operations outside Gitea’s data directory.

SIEM query (generic web log):

uri_path:"*/diffpatch"
AND method:POST
| stats count by src_ip, uri_path
| where count >= 2

Flag any source IP submitting two or more diffpatch requests to the same repository within a short window for manual review.

Timeline

References

• Gitea Security Advisory — GHSA-rcr6-4jqh-j84m
• NVD Entry — CVE-2026-60004
• CISA Known Exploited Vulnerabilities Catalog
• CISA BOD 26-04 Guidance
• The Hacker News — New Gitea RCE Lets Repository Writers Plant a Git Hook to Run Shell Commands