CISA has added CVE-2026-60004 to its Known Exploited Vulnerabilities catalog after confirming exploitation of the critical Gitea code-injection flaw. Administrators running Gitea 1.17 through 1.27.0 should upgrade to 1.27.1 or later immediately, preserve relevant logs, and review accounts and repositories created while the server was exposed. The vulnerability can turn ordinary repository write access into shell-command execution as the Gitea operating-system user.
The important boundary is that an attacker needs permission to write to a repository. However, a Gitea instance with open registration and permission for new users to create repositories can give an unauthenticated visitor that access after self-registration. Disabling registration lowers the exposure, but it does not protect a vulnerable server from a compromised or malicious existing writer.
Who Is Affected by CVE-2026-60004?
The upstream advisory lists Gitea versions from 1.17 up to, but not including, 1.27.1 as affected. Exploitation also depends on Git 2.32 or newer, an enabled diffpatch route, and a writable, executable temporary filesystem.[2]
| Situation | Risk and action |
|---|---|
| Gitea 1.17–1.27.0 with the trigger conditions | Vulnerable. Upgrade to 1.27.1 or a newer supported release now. |
| Open registration and repository creation | A visitor may self-register, create a repository, and obtain the write access needed for the attack. Restrict both controls while patching. |
| Registration disabled | The no-prior-account path is blocked, but existing writers, stolen accounts, and compromised tokens still matter. |
| Gitea 1.27.1 or later | The specific diffpatch Git-hook flaw is fixed. Continue the compromise review if the instance was previously vulnerable. |
CISA set an August 28, 2026 remediation deadline for covered federal systems and lists ransomware use as unknown.[1] That deadline is not a safe waiting period for other organizations: an internet-facing, vulnerable instance should be treated as an urgent patch-and-hunt case.
How the Gitea Git-Hook RCE Works
Gitea applied attacker-controlled patches inside a shared bare temporary clone. By submitting the same crafted patch twice, an attacker could create an add/add collision and trigger Git’s three-way fallback. In a bare clone, the repository root is also $GIT_DIR, so an executable file placed at hooks/post-index-change became a live Git hook instead of an ordinary repository file.
Git then executed that hook while updating the index. The command ran as the Gitea service account, and the advisory’s proof of concept could return output through Git objects without requiring an outbound connection. The hook’s return value was not propagated to the API response, so a normal-looking diffpatch response does not prove that exploitation failed.
Gitea 1.27.1 changed the patch workflow so the temporary clone is no longer bare, preventing a repository path from becoming a live hook in $GIT_DIR.[3]
What Gitea Administrators Should Check Now
- Record the current state before changing it. Capture the Gitea version, registration and repository-creation settings, Git version, service-account identity, running processes, active connections, and relevant access and application logs.
- Upgrade to 1.27.1 or later. Use the current supported release for your deployment method, test the upgrade, and confirm that every node or container was replaced rather than leaving an older instance behind.
- Review the
diffpatchroute. Search API and reverse-proxy logs for repeated requests to paths matching/api/v1/repos/{owner}/{repo}/diffpatch, especially pairs close together in time. - Correlate account and repository events. Look for new registrations, newly created repositories, unexpected writers, token use, and patch activity from the same source, account, or time window.
- Hunt beyond web logs. Inspect child processes launched by the Gitea service, shell execution, unusual file access, changes to repositories, and unexpected reads of configuration, database, OAuth, or integration secrets. Temporary clone cleanup can remove the planted hook itself.
If you operate another self-hosted Git service, do not assume the same flaw applies. The practical hardening questions do overlap, though: restrict registration, limit who can create repositories, review writer access, and isolate the service account. Our Gogs RCE guide explains why open registration can turn a permission boundary into an attack path on a different platform.
What to Do If Exploitation Is Suspected
Isolate the affected Gitea server or container without destroying volatile evidence. Preserve logs, process information, the database, repositories, configuration, mounted volumes, and a forensic copy of the host before rebuilding from a trusted image. Do not rely only on the absence of the temporary Git hook: the attacker may have executed commands and left persistence elsewhere.
After containment, rotate Gitea application secrets, database credentials, OAuth and integration credentials, deploy keys, access tokens, and any credentials available to the service account. Revoke active sessions and review repository contents, hooks, Actions secrets, releases, packages, and recent administrative changes. Rotate secrets from a clean administrative system, not from the potentially compromised server.
A vulnerable version or open registration proves exposure, not compromise. Conversely, a successful upgrade removes the known entry point but does not undo commands that may already have run. The decision should come from correlated API, account, process, file, repository, and credential evidence.
References
- Cybersecurity and Infrastructure Security Agency. “CISA Adds One Known Exploited Vulnerability to Catalog.” CISA, August 25, 2026. CISA alert.
- Gitea Project. “Remote Code Execution via diffpatch Git Hook Installation.” GitHub Security Advisory GHSA-rcr6-4jqh-j84m, published July 28, 2026; accessed August 25, 2026. Gitea security advisory.
- Gitea Project. “Gitea 1.27.1 Is Released.” Gitea Blog, July 27, 2026. Gitea release notice.
