Advisory · CVE-2026-60004
A crafted patch turns Gitea into a shell
An attacker with write access to a Gitea repository can abuse the diffpatch API to plant an executable Git hook and run arbitrary commands as the Gitea service account.
- Vendor
- Gitea
- Product
- Gitea
- Identifier / CWE
- CVE-2026-60004
CWE-94 - Action timing
- Sep 15, 2026
Explain it like I’m five
Gitea lets people mail in suggested edits, but its mailroom glues two identical envelopes together and leaves the result where the building's alarm installer looks. The attacker hides an alarm installer of their own, and the building runs it with the keys to everything.
- 01Write access obtained
The attacker holds ordinary write access to a repository. With open registration enabled, an unauthenticated visitor can get it by signing up and creating a repo.
- 02Patch submitted twice
The attacker submits the same malicious patch twice to the diffpatch API, causing an add/add collision.
- 03Hook planted
Git's three-way fallback checks an executable entry out of a shared bare clone where the repository root is the Git directory, so the entry becomes a live Git hook.
- 04Hook fires
Git invokes the hook while writing the index, executing the attacker's shell commands as the Gitea service account.
What happened
On August 25, 2026, CISA added CVE-2026-60004 to the Known Exploited Vulnerabilities catalog. It is a code injection flaw in Gitea, rated critical at CVSS 9.8, fixed in Gitea 1.27.1.
The diffpatch API endpoint applies attacker-controlled patches in a shared bare temporary clone. Submitting the same patch twice creates an add/add collision, and Git’s three-way fallback checks the indexed path out even though the operation runs with --cached. In a bare clone the repository root is the Git directory itself, so an executable entry named hooks/post-index-change lands as a live Git hook. Git invokes the hook while writing the index, which executes the attacker’s shell commands as the Gitea OS user.
The privilege needed is ordinary repository write access, not administrator. With default open registration, an unauthenticated visitor can obtain that access by registering a normal account and creating a repository. Public proof-of-concept code stores command output in Git objects and exfiltrates it through normal authenticated fetches, so exploitation does not even require outbound network access from the server.
What to do
- Upgrade all Gitea instances to 1.27.1 or later; Gitea’s release notes list this fix as a security update and urge upgrading as soon as possible.
- Review whether open registration is enabled, and disable it or gate it behind approval while you assess exposure.
- Hunt for exploitation: review application logs for repeated diffpatch submissions, new repositories created by fresh accounts, and unusual child processes or command execution under the Gitea service account.
- Audit repositories for unexpected branches or objects that could hold exfiltrated command output.
- If compromise is suspected, rotate the Gitea service account credentials and secrets, and rebuild affected hosts from known-good state.
- Confirm the running version after the upgrade and verify open registration policy matches your intent.
Management note
Your code forge holds your crown jewels, and this flaw lets anyone with a free account trade repository write access for shell on the server. The unauthenticated path is the dangerous part: self-hosted Gitea with open signups is effectively offering command execution to the internet. Patch immediately and reconsider whether open registration should exist at all on a server that builds your software.