Threat feed
CVE-2026-60004 — code injection in Gitea leading to command execution on the server
Code injection (CWE-94, CVSS 9.8, KEV) in Gitea's diffpatch endpoint, fixed in 1.27.1. CVSS says no privileges required, CISA says write access is — both are right, because open registration grants it.
A briefing on a vulnerability with confirmed exploitation (listed in CISA KEV): what happens, what is affected and what to do — from the defender's side, with no reproduction steps.
- CVE
- CVE-2026-60004
- Severity
- Critical (CVSS 9.8, v3.1; the score recorded in NVD is attributed to the CVE numbering authority)
- Class
- Code injection (CWE-94)
- Impact
- A malicious Git hook is installed → commands run as the Gitea OS user
- Affected
- Gitea 1.17 – 1.27.0 per the vendor advisory. Fixed in 1.27.1
- Exploitation
- Listed in CISA KEV (added 25 August 2026, due 28 August). Ransomware campaign use recorded as "Unknown"
- Likelihood
- EPSS 0.868 (from our feed as of 2026-09-05) — top tier
Do not read "privileges required" as reassurance
Reading A (CISA's description)
"an attacker with repository write access" — sounds conditional
Reading B (the CVSS vector)
PR:N — no privileges required
↓ the vendor advisory explains both
With open registration enabled
register → create a repository → grant yourself the write access the attack needs
Taking comfort from "but it requires privilege X" is a common way to misjudge a vulnerability. The question is not who holds that privilege but whether the privilege can be obtained from outside. Open registration, invite-free sign-up, permissions granted by default — a privilege with an acquisition path is not really a condition.
That reframing is the same as bucket ② in common mistakes are failures of assumption. And check the registration path over HTTP rather than in the config file (authentication vs authorization).
What the flaw is
- Path
- The
diffpatchendpoint mishandles patch application in shared temporary clones - Result
- A malicious Git hook (
hooks/post-index-change) can be installed - Trigger
- The hook executes as the Gitea OS user when Git writes the index
- Reachable from there
- Application secrets, database credentials, OAuth tokens, mounted repositories
- Preconditions
- The vendor notes exploitation requires Git 2.32+, the
diffpatchroute enabled, and a writable, executable temporary filesystem
What remains is an artefact — which is why updating is not the end
This one ends in something executable left on the server. Updating closes the path that installs it; it does not remove anything already installed.
A Git hook is designed to be a legitimate remote-execution point, so once one is in place it does not look suspicious. The only thing separating legitimate maintenance from a backdoor is who created it, with whose permission, and whether it shows up in the record. After closing the hole, look for what stayed behind — do not skip that order.
What to do
Update to 1.27.1 or later (the main action)
The vendor advisory gives the affected range as 1.17 – 1.27.0 and the fix as 1.27.1. Start here. Nobody updates a self-hosted instance for you — measure the running version first, as in the CVE remediation playbook.
Check the registration setting for real
As above, whether open registration is on is what effectively removes the privilege condition. Do not read the setting — open the registration page while logged out and see what happens. For an internal instance, close registration and restrict reachability at the network layer rather than relying on authentication alone.
Look for hooks and files you do not recognise
After updating, check for scripts in repository hook directories that you did not put there, unexpected executables, and unfamiliar outbound traffic from the Gitea process. The question is not "did we update" but "was anything left behind".
If compromise is plausible, treat the reachable set as exposed
What the vendor lists as reachable is application secrets, database credentials and OAuth tokens. If your inspection cannot settle the question, remember that "we don't know" is not "nothing happened" — rotate them. Key handling is in what is dangerous about .env and API keys.
Revisit the choice itself (no rush)
Running it yourself comes bundled with the duty to update it yourself. The trade-offs are in self-hosted Git versus GitHub, which is safer. This is not an argument to migrate — it is an argument to decide based on whether you can actually keep updates flowing.
This site's view: CVSS and KEV are measuring different things, so read both
This case turned into a worked example of what we wrote in CVE triage with CVSS, EPSS and KEV. CVSS says how bad it is technically, CISA's entry says how it is being used in the field, and EPSS estimates the probability of exploitation — three different measurements.
Here the CVSS PR:N and CISA's "write access required" looked contradictory. Reading only one of them, you would have concluded "it needs a privilege, so this can wait". A discrepancy is rarely an error in the data; it is a signal that some premise has been missed — and in this case the vendor advisory held the answer (open registration).
Sources (primary)
- Gitea security advisory GHSA-rcr6-4jqh-j84m — github.com (affected 1.17–1.27.0 / fixed in 1.27.1 / the privilege condition and its relation to open registration / what is reachable / the preconditions)
- NIST NVD, "CVE-2026-60004" — nvd.nist.gov (CVSS v3.1 9.8, the vector, CWE-94; status Analyzed)
- CISA Known Exploited Vulnerabilities Catalog — cisa.gov (added 25 August 2026, due 28 August, ransomware campaign use "Unknown")
- Gitea, "Release of 1.27.1" — blog.gitea.com
All checked on 5 September 2026. No reproduction steps and no links to proof-of-concept code are published here.
Read next
- The trade-off: self-hosted Git versus GitHub, which is safer
- Process: the CVE remediation playbook / reading CVSS, EPSS and KEV
- Glossary: what a backdoor is (how to think about what was left behind)
FAQ
QWhat happens with CVE-2026-60004?
According to the vendor's security advisory, the diffpatch endpoint mishandles patch application, and the result is that a malicious Git hook (hooks/post-index-change) can be installed. That hook executes as the Gitea OS user when Git writes the index. The vendor lists application secrets, database credentials, OAuth tokens and mounted repositories among what becomes reachable.
QIs authentication required? CVSS says no privileges, CISA says repository write access.
Both are correct and they do not conflict. The vendor advisory states that write access to a repository is necessary, and then explains that where open registration is enabled an unauthenticated user can register an account and create a repository to obtain exactly that access. In other words, when the required privilege can be obtained by anyone, it is effectively not a requirement — which is what the CVSS vector reflects.
QWhich versions are affected, and how is it fixed?
The vendor advisory gives the affected range as 1.17 through 1.27.0, with 1.27.1 as the patched release. The fix is to update to 1.27.1 or later. A self-hosted Gitea does not update itself, so the longer an instance is left alone, the longer it stays exposed.
QIs updating the end of it?
Updating is the main action but not the whole job. What this vulnerability ends in is an executable artefact left on the server — a Git hook — and updating closes the path that installs one without removing anything already installed. After updating, check for hooks or files you do not recognise, and confirm the registration setting is what you intended. If a compromise looks plausible, treat what the vendor lists as reachable — secrets, database credentials, OAuth tokens — as exposed and rotate them.