New Gitea RCE Lets Repository Writers Plant a Git Hook to Run Shell Commands

# Gitea RCE (CVE-2026-60004): Any Registered User Can Execute Shell Commands via Malicious Patch

## The Threat

A critical remote code execution vulnerability in Gitea allows any user with repository write access to plant a Git hook that runs arbitrary shell commands as the Gitea service account. The attack weaponizes the platform's patch-apply API endpoint — specifically POST /api/v1/repos/{owner}/{repo}/diffpatch — by exploiting how Gitea creates bare temporary clones when applying patches. In a bare repository, the working tree root is $GIT_DIR itself. An attacker who submits a crafted patch twice can trigger an add/add merge collision; the three-way fallback (available when the server runs Git 2.32 or later) checks out the conflicting path directly into that directory, placing an executable file at hooks/post-index-change — exactly where Git looks for hooks to run during index updates.

The second piece that makes this devastating in practice: Gitea ships with open registration enabled by default. New accounts require no email verification, no admin approval, and carry no restrictions on repository creation. That means an untrusted outsider can create a fresh account, spin up a private repository, and exploit this bug without any pre-existing foothold on the installation. The attack is entirely self-contained — the PoC doesn't even require an outbound callback channel. Command output is written into Git objects, pushed to a branch, and fetched back over authenticated smart HTTP.

What an attacker gains depends on how tightly the Gitea instance is isolated, but the service account typically has access to application secrets, OAuth credentials, mounted repositories, database connection strings, and anything else reachable on the internal network. This is not a privilege escalation within Gitea — it is host-level code execution as whatever OS account runs the service.

## Severity and Impact

| Field | Detail |

|---|---|

| CVE | CVE-2026-60004 |

| CVSS Score | 9.8 (Critical) |

| Attack Vector | Network |

| Attack Complexity | Low |

| Privileges Required | Low (trivially obtained via open registration on default installs) |

| User Interaction | None |

| CWE | CWE-77 — Improper Neutralization of Special Elements Used in a Command |

| Exploit Available | Yes — public PoC included in Gitea's own advisory |

| Exploitation in the Wild | Not confirmed as of July 29, 2026 |

## Affected Products

Gitea (self-hosted)

Not affected:

## Mitigations

Primary fix — upgrade immediately:

Workarounds while patching:

Verification:

Confirm your version with gitea --version or via the admin panel. If you are running a containerized deployment, pull the updated image and verify the base version before assuming you are patched.

## References

---

## HackWire Analysis

Two things about this vulnerability deserve more attention than the patch headline suggests.

First, the changelog burial. Gitea merged the fix on July 26 and shipped 1.27.1 on July 27 — a competent turnaround. But the release notes categorized the critical change as a MISC refactor: *"refactor: git patch apply."* No SECURITY tag. No CVE callout. No hint that this was anything other than housekeeping. For any operator running automated dependency checks keyed to SECURITY-labeled changes, this was effectively invisible. That is not a minor process failure — it is exactly the kind of omission that allows critical patches to sit undeployed for weeks on self-managed infrastructure while teams assume nothing important shipped.

Second, the default-configuration attack surface is the real story. Gitea's open-registration default is a reasonable choice for internal developer tooling behind a VPN, where friction on new contributors matters. It becomes a liability the moment an instance is internet-exposed — and self-hosted Git servers routinely end up public-facing. The combination of open registration, unrestricted repository creation, no email verification, and no restricted-user default means a fresh Gitea install is functionally open to unauthenticated exploitation by anyone who can reach port 3000. Operators who hardened registration are naturally protected from the public-account path. Everyone else should assume their exposure window started the moment 1.17 shipped in their environment.

For defenders: treat this like a CI/CD supply chain risk, not just a web application vuln. Gitea is often positioned upstream of build pipelines, secret vaults, and artifact registries. Compromise of the Gitea service account can cascade into those systems. Inventory your Gitea instances, check what the service account can reach, and patch before the PoC gets scripted into mass-scanning toolkits — which, with a public exploit and a 9.8 score, is a question of days, not weeks.

— HackWire Editorial

---

## Related Coverage