Security1 distinct publisher2 min readPublished
CVE-2026-60004 scores 9.8, but the reason it needs same-day attention is that Gitea ships with self-registration enabled, so the write access the exploit needs costs an attacker one signup. Only 1.27.1 fixes it.
The Watch · Security desk
Compiled by The WatchSomething wrong?How this is made
The fix is one word deep in the clone setup. Gitea changed the temporary clone from bare to non-bare, and the code comment left behind warns that Git commands using `--index` may operate on the working tree [8]. In a bare repository the root is `$GIT_DIR`, so an executable written to `hooks/post-index-change` lands in Git's live hook directory, and Git runs it while updating the index [7]. The route that gets you there is `POST /api/v1/repos/{owner}/{repo}/diffpatch`, which applies a supplied patch inside a shared bare temporary clone [4]. Vulnerable builds call `git apply` with `--index`, `--recount`, `--cached` and `--binary`, adding the `-3` three-way fallback when the server runs Git 2.32 or later [5]. Submit the same patch twice, get an add/add collision, and the fallback checks the indexed path out to disk despite `--cached` [6].
The 9.8 [1] is doing less work here than the precondition list. Exploitation needs repository write access, Git 2.32 or later, the diffpatch route enabled, and a temporary filesystem that is both writable and executable [17]. The authentication gate is real but shallow: the affected route calls `reqToken()`, which only rejects requests without a signed-in user [14], and Gitea's defaults leave registration open, ask for neither email verification nor manual approval, do not mark new accounts restricted, and set no repository-creation limit [15]. On an unchanged installation an outside visitor creates an account and a repository, then exploits the bug with no pre-existing credentials [24].
The vulnerable range covers eleven minor release lines, 1.17 through 1.27.0 [1][25]. It also left two days between the public commit and the advisory [22], during which the only description available to an admin reading the changelog was "refactor: git patch apply", filed under MISC rather than SECURITY [10].
Shai Rod, credited by Gitea as NightRang3r [19], had previewed the RCE alongside a file-inclusion issue, with a PoC that pulled `/etc/passwd` from a Gitea 1.27.0 host; that appears to match a separate 1.27.1 change making the Org-mode renderer return `#+INCLUDE` paths as plain text, and Gitea has published no advisory or CVE for it [21]. So 1.27.1 carries a second security change with no tracking ID. On exploitation there is no record either way: as of July 29, none of the primary sources says whether the flaw was used before or after 1.27.1 became available [20].
Ranked by verification strength, evidence, and original report placement.
Gitea patched a critical remote code execution vulnerability tracked as CVE-2026-60004 with a CVSS score of 9.8, affecting Gitea versions 1.17 and later before 1.27.1 and fixed in 1.27.1.
A user with ordinary repository write access can turn attacker-controlled patch content into a live Git hook and run shell commands as the Gitea service account.
The bug sits in the POST /api/v1/repos/{owner}/{repo}/diffpatch endpoint, which applies a supplied patch inside a shared bare temporary clone.
Vulnerable builds invoke git apply with --index, --recount, --cached and --binary, adding 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, and Git runs it while updating the index.
Distinct publishers with included, body-backed reporting in this cluster.
1 article · August 27, 2026
Follow any of these and your For You feed starts watching them — no settings page required.
build
The stability step is a branch, not a pipeline: inside one team's release-candidate discipline1 distinct publisher
build
Five coding agents on one repo is a staffing problem, and worktrees only fix the filesystem1 distinct publisher
build
Waku 0.1.0 bets the product is the control plane, not another coding agent1 distinct publisher
build
Parallel coding agents on Windows break at the home directory, not the launcher1 distinct publisher
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Primary-artefact detail, single reporting outlet
The technical account is unusually specific and traceable to primary artefacts the report names: the vendor advisory (endpoint, flag set, impact scope), the commit that changed the temporary clone from bare to non-bare with its code comment, the 1.27.1 release notes classification, and published PoC code. Dates for merge, release and advisory are given individually. The ceiling is that all of this reaches the cluster through one publisher, with no independent newsroom replication and no vendor statement obtained on the MISC classification or the uncredited file-inclusion change.
Vendor-side remediation shipped, field uptake unknown
Concrete adoption facts exist only on the supply side: the fix was merged and backported, 1.27.1 shipped the next day, the advisory followed, and Gitea Cloud instances were said to be auto-upgraded. Nothing in the cluster measures the demand side - no count of exposed or upgraded self-hosted instances, no scan telemetry, and no report of exploitation before or after 1.27.1. With an eleven-minor-line vulnerable range, unremediated self-hosted population is plausibly large but unquantified here, so the score reflects confirmed vendor-side remediation only.
Roughly aligned, with mild urgency framing ahead of evidence
The reporting is close to calibrated: it states the authentication requirement, lists all four exploitation preconditions, limits the registration workaround, and says outright that no cited primary source addresses exploitation. The small positive gap comes from urgency framing - the dek's same-day emphasis and the 9.8 headline - resting on a default-configuration inference rather than on any observed attack or exposure measurement, and from the impact list being Gitea's conditional 'depending on isolation' scenario presented as blast radius. Interestingly, the vendor understated in the opposite direction by filing the fix as a MISC refactor.
Visible vendor-signalling and disclosure-credit incentives
Interests are identifiable from the cluster's own facts rather than inferred. Gitea classified a 9.8 fix in release notes as a MISC refactor and shipped a related file-inclusion change with no advisory or CVE, both consistent with downplaying security signalling; it also highlighted automatic Cloud upgrades, which favours the hosted product. The reporting researcher is publicly credited and had previewed the findings, an attention-linked incentive. The publisher is a security-trade outlet for which a critical forge RCE is high-traffic material. Scored mid-range because these are structural observations, not documented statements of motive.
Well-anchored but unreplicated and partially stale
Confidence is supported by dense, artefact-level specificity and by the report's explicit marking of what it does not know. It is held down by three things: a single publisher with no independent corroboration, the absence of any field measurement of exposure, upgrade uptake or exploitation, and a timing mismatch - the events and the report's own cutoff are late July 2026 while this item published a month later, so downstream developments such as observed exploitation or a CVE for the file-inclusion issue would not be captured.