CISA added a critical Gitea code-execution flaw to its Known Exploited Vulnerabilities catalog on August 25. The entry changes a month-old patch into an active incident priority for organizations that run their own Gitea code-hosting servers.
The Gitea advisory says versions 1.17 through 1.27.0 are affected by CVE-2026-60004.
Active exploitation raises priority
The Canadian Cyber Centre’s August 25 advisory records CISA’s addition of CVE-2026-60004 to the KEV catalog and directs administrators to the vendor’s updates. That establishes exploitation in the wild. The primary records do not identify the attackers, their targets, a victim count, or the payload used after entry.
Scope still matters. An attacker needs ordinary write access to a repository. A Gitea instance with default open registration lets a visitor create an account and repository, satisfying that prerequisite without an existing credential. Closed registration removes that route, although any compromised or malicious repository writer can still reach the vulnerable behavior.
The vendor also lists three technical conditions: Git 2.32 or newer, an enabled diffpatch route, and a temporary filesystem that is both writable and executable. Those conditions help triage exposure. They do not provide a substitute for the fixed build once an affected instance has been reachable by untrusted writers.
Gitea does not quantify how many installations meet that combination. CVSS scores the issue 9.8, and the potential reach depends on the service account. A successful command can expose app.ini, process-environment secrets, mounted repositories, database credentials, OAuth or integration credentials, and services reachable from the host.
A patch becomes a hook
The vulnerable path applies user-controlled patches inside a shared bare temporary clone. The trigger appears when the same patch is submitted twice. The second submission creates an add/add collision, so Git’s three-way fallback checks the indexed path out even though Gitea invoked git apply with --cached.
In a bare clone, the repository root is $GIT_DIR. An executable file at hooks/post-index-change therefore lands in Git’s live hook directory. Git runs that hook while updating the index, giving repository content a command path under the Gitea operating-system account.
The vendor’s concise description is worth preserving: “Gitea’s diffpatch endpoint can be abused to install and execute a Git hook from repository-controlled content.” The hook’s return value does not reach the API response, so a quiet or apparently failed client interaction cannot attest that the host stayed clean.
The published proof of concept stores command output in Git objects and exposes it through a branch. It needs no outbound callback. That is a useful detection lesson: network monitoring alone can miss the execution path because both delivery and retrieval can remain inside normal-looking Gitea and Git traffic.
Figure details
A linear chain begins when the same payload passes through diffpatch twice. The duplicate creates a collision and invokes Git's three-way apply. An executable file then lands at hooks/post-index-change inside the bare clone, where Git invokes it as the Gitea service account. A final evidence boundary states that CISA confirms exploitation while the primary records do not identify actors, victims, or payloads.
Recognize the exposed path
Start with a version inventory. The public version endpoint gives defenders a fast first check:
curl -fsS https://gitea.example/api/v1/versionTreat any result from 1.17 through 1.27.0 as affected. Confirm the actual package, container image, or binary on the server as well, because a reverse proxy or cached response can misrepresent the running workload.
Next, establish whether untrusted users could acquire repository write access. Check the live registration state and the account-creation history. Review Gitea application and reverse-proxy records for repeated requests to paths shaped like POST /api/v1/repos/<owner>/<repo>/diffpatch, especially two closely spaced submissions against a newly created repository.
That request pattern is a lead rather than proof of compromise. The endpoint has legitimate uses, and an attacker can vary repository names and cleanup behavior. Pair it with host evidence: unexpected child processes under the Gitea service account, short-lived executable files under Gitea’s temporary storage, unexplained CPU spikes, new repositories from recently registered accounts, or branches that carry unusual output-like blobs.
Preserve the relevant Gitea logs, reverse-proxy logs, service-manager journal, process telemetry, repository metadata, and temporary-directory evidence before cleanup. The cited primary sources publish no campaign domains, IP addresses, file hashes, miner family, wallet, or operator. Generic indicators attributed to this CVE would overstate the available evidence.
Prove the upgrade holds
Gitea 1.27.1 fixed CVE-2026-60004 on July 27. Upgrade to Gitea 1.27.2 or a newer supported release for the additional security fixes included in the August 14 release.
Verify the externally reported version, then compare it with the package, image digest, or binary that the service manager actually starts. The expected result is 1.27.2 or newer across every active node, with no 1.17-through-1.27.0 process left behind. Test account registration from the untrusted side and confirm it matches policy. Review the period before the upgrade for repeated diffpatch requests, unexpected service-account children, new repositories, unusual branches, and executable remnants in temporary storage.
A clean version response proves the replacement is serving traffic. It says nothing about what an earlier process executed. Active exploitation makes the historical review part of the patch, because the vulnerable mechanism was built to turn repository content into host behavior without needing a separate callback channel.