Gitea RCE CVE-2026-60004: Git Hook Bug, How to Patch

A critical flaw in Gitea, the popular self-hosted Git service, lets an attacker turn ordinary repository access into remote code execution on the server. Tracked as CVE-2026-60004 and rated 9.8 on the CVSS scale, the bug allows a user with repository write permission to plant a malicious Git hook that runs arbitrary shell commands with the privileges of the Gitea process. Gitea disclosed the issue on July 28, 2026, alongside a fix in version 1.27.1 — and the advisory shipped with public proof-of-concept code, sharply raising the odds of opportunistic exploitation.

The vulnerability

CVE-2026-60004 affects Gitea versions 1.17 and later, before 1.27.1, and is fixed in 1.27.1. At its core, the flaw abuses Gitea’s handling of Git hooks — the scripts Git runs automatically at defined points in a repository’s lifecycle.

The exploit path is a repository write that Gitea should never have allowed to reach the hook machinery. Through a vulnerable API call, a user with write permission on a repository can install or modify a server-side Git hook whose contents they control. Because those hooks execute on the Gitea server host when triggered by ordinary Git operations, a crafted hook becomes a direct channel to run shell commands on the machine — the classic pattern of turning “I can write to a repo” into “I can run code on your server.”

Two properties make the severity worse than a first read suggests. First, the vulnerable operation requires only repository write permission, not administrative access — a much lower bar on any multi-user instance. Second, Gitea enables self-registration by default. On an unchanged installation, that means an outside visitor can simply create an account, create a repository, and reach the vulnerable code path without any pre-existing credentials at all. The combination of network-reachable, low-privilege, and full command execution is exactly what pushes the CVSS score to 9.8.

The flaw was reported by security researcher Shai Rod, who goes by NightRang3r.

Why Git hooks are dangerous by design

To understand why this bug is so severe, it helps to understand what Git hooks are. Hooks are scripts that Git executes automatically in response to events — a pre-receive hook runs before the server accepts a push, an update hook runs per-branch, a post-receive hook runs after new commits land. Server-side hooks are enormously useful for enforcing policy, triggering builds, or integrating with other systems.

They are also, by their nature, arbitrary code that runs on the server. A hook is a shell script executing with the privileges of whatever process invoked it — on a Git host, that is the service account running the Git server software. This is why mature Git platforms treat the ability to define custom server-side hooks as a privileged, admin-only capability. Gitea itself has historically gated custom hooks behind administrative controls precisely because installing one is, functionally, equivalent to being handed a shell.

CVE-2026-60004 is dangerous because it bypasses that gating. It lets a mere repository writer — or, given default registration, effectively anyone — reach functionality that should have been reserved for administrators. The mechanics differ, but the shape of the risk echoes other recent server-side RCEs, from the command-injection zero-day in Arista’s VeloCloud Orchestrator to the critical remote-code-execution flaw in JetBrains TeamCity. In each case, a feature meant to run trusted code on a server became a lever for untrusted users.

The timeline and the public PoC

The disclosure moved quickly, and it left little slack for defenders. According to Gitea’s advisory, the fix was merged and backported on July 26, 2026; version 1.27.1 shipped on July 27; and the security advisory, including public proof-of-concept code, followed on July 28. Gitea also said that Gitea Cloud instances would be upgraded automatically, protecting hosted customers without action on their part.

For self-hosted operators, the equation is different — and the presence of a public PoC changes the calculus. When working exploit code is published alongside an advisory, the barrier to exploitation collapses: an attacker no longer needs to reverse-engineer the patch or rediscover the flaw, only to point an existing script at an unpatched instance. Given that Gitea installations are frequently internet-exposed and often run with open registration, the population of reachable, exploitable targets on disclosure day was almost certainly non-trivial. This is the same compressed disclosure-to-exploitation window that has defined the year’s security story, and it is precisely the dynamic that makes a malicious proof-of-concept a supply-chain hazard in its own right.

What operators should do

The fix is unambiguous and should not wait for a routine maintenance cycle.

• Upgrade to Gitea 1.27.1 immediately. This is the fix; every version from 1.17 up to but not including 1.27.1 is vulnerable.
• Disable open registration if it is not essential. Turning off self-service account creation removes the anonymous path to the vulnerable code and shrinks the attack surface to authenticated, write-capable users. On any internet-exposed instance, open registration and a repo-write RCE are a dangerous combination.
• Review write access. Audit who holds write permission across repositories and organizations, and prune accounts and tokens that do not need it. The bug’s low privilege requirement means every writer is a potential entry point until you patch.
• Assume potential compromise for any instance that was internet-exposed and unpatched after July 28, particularly one with open registration. Hunt for unexpected processes, outbound connections, or new files on the server host, and for unfamiliar accounts or repositories created around the disclosure window.
• Rotate secrets the Gitea host can reach — deploy keys, CI/CD tokens, and integration credentials — if compromise cannot be ruled out. A Git server sits at the center of the software supply chain, with access to source code and often to the pipelines that build and deploy it.

The structural lesson is the recurring one for any system that runs code on behalf of users: the boundary between “can contribute” and “can execute” must be enforced deliberately and defended in depth. A zero-trust posture — keeping management and self-hosted developer tooling off the open internet, requiring strong authentication to reach it, and never treating write access as harmless — is the architectural answer to a class of bug that keeps surfacing in the tools that hold source code.

What it means

CVE-2026-60004 is a textbook example of how a legitimate feature becomes a critical vulnerability when a privilege boundary fails. Git hooks are supposed to run trusted, admin-defined code on the server; this flaw let ordinary repository writers — and, on default installs, anonymous self-registered users — supply that code themselves. The result is full command execution on the host, rated 9.8, with a public exploit in circulation.

Who is exposed. Self-hosted Gitea instances on versions 1.17 through 1.26.x that are internet-reachable, especially those running with the default open registration. Gitea Cloud users were auto-upgraded; everyone else has to patch themselves, and the published PoC means the window for doing so quietly has already closed.

Why it matters beyond one server. A Git host is not just another application — it holds an organization’s source code and frequently the credentials that drive its build and deployment pipelines. Code execution on that box is a foothold into the software supply chain, which is why a repo-write RCE deserves the same urgency as a flaw in an edge appliance.

What to watch. Whether opportunistic scanning turns into named intrusions over the coming weeks, and whether the incident nudges self-hosted Git platforms toward disabling open registration by default. For now the action item is narrow and immediate: upgrade to 1.27.1, close open registration where you can, and treat any exposed, unpatched instance as suspect until proven clean.