Short answer. If you self-host Gitea 1.17 through 1.27.0, upgrade to 1.27.1 today. CISA added this flaw to the Known Exploited Vulnerabilities (KEV) catalog on August 25, 2026 and set a remediation due date of August 28, 2026 for US federal agencies. It is remote code execution that is already being exploited in the wild, and the maintainers published no workaround — upgrading is the only fix.
What actually happens
Submitting the same patch twice to Gitea's `diffpatch` API creates an add/add collision. Git then falls back to its three-way merge path, which checks out indexed paths even during cached operations. Because a bare repository uses `$GIT_DIR` as its root, an executable entry named `hooks/post-index-change` becomes a live Git hook. From there the attacker's commands run as the Gitea service account.
The advisory states that this exposes application secrets, database credentials, mounted repositories, and OAuth tokens.
Get the preconditions right
The CVSS 3.1 vector is `AV:N/AC:L/PR:N/UI:N`, but that `PR:N` assumes an instance where anyone can register. The advisory states the attacker needs either write access to an existing repository, or the ability to create a new one. Gitea allows open registration by default, so on a default instance an effectively unauthenticated attacker does meet the condition. CISA, by contrast, describes the same flaw as requiring "repository write access".
Closing registration does not close the hole: any existing account with write access still satisfies the precondition. Do not treat "registration is disabled" as safe.
Affected and fixed releases
- ▸Affected: Gitea 1.17 through 1.27.0 (inclusive)
- ▸Fixed: Gitea 1.27.1
- ▸The MITRE CVE record expresses this as version 1.17, lessThan 1.27.1
- ▸CWE-94 (Improper Control of Generation of Code)
Checks to run now
- ✓Confirm the running Gitea version and upgrade to 1.27.1 or later
- ✓If the upgrade will take time, confirm whether the instance is reachable from the Internet
- ✓Inventory accounts with repository write access, and review whether open registration is enabled
- ✓Inspect each repository's hooks directory for executable files you did not create
- ✓Investigate unexpected processes owned by the Gitea service account and any credential exposure in its config
- ✓If you find signs of exposure, rotate OAuth tokens and database credentials after upgrading
# Check the running version
gitea --version
# If you run it under Docker
docker exec <container-name> gitea --versionExploitation status and deadline
CISA added the CVE to KEV on August 25, 2026, with a due date of August 28, 2026. Known ransomware campaign use is listed as "Unknown". runZero reports that there is evidence CVE-2026-60004 is being actively exploited in the wild.
Worth noting: the KEV listing (August 25) came before the NVD record was published (August 26). "It is not in NVD yet, so we can wait" is not a viable position on this one.
Where the score comes from
The 9.8 in this article is the CVSS 3.1 value supplied by MITRE as the assigning authority, as shown on NVD. As of August 27, 2026 the NVD entry is still marked "Undergoing Analysis", meaning NVD has not yet published its own primary assessment. If NVD later scores it independently, the number or severity band may change. If you open NVD and see a different figure, this is why.
The other fix in 1.27.1
Gitea's release announcement states that 1.27.1 also contains a second security fix: an unauthenticated arbitrary file read via the Org-mode `#+INCLUDE` directive. However, at the time of checking, the identifier assigned to that issue was present in neither NVD nor MITRE. This site does not publish identifiers it cannot verify, so no number is given here. Either way, upgrading to 1.27.1 resolves both issues.