CVE-2026-60004

What is Gitea?

Gitea is a lightweight, self-hosted Git service written in Go — a popular open-source alternative to GitHub/GitLab for teams that want to run their own source-code hosting. A single binary provides the web UI, repository storage, issue tracking, and a REST API. Because Gitea instances hold an organization's source code and often run with broad filesystem access on the host, and because many are exposed to the internet with open self-registration enabled by default, a remote code execution flaw makes them a high-value target for opportunistic attackers.

Overview

CVE-2026-60004 is a code-injection vulnerability (CWE-94) in Gitea's diffpatch API endpoint. An attacker with ordinary repository write access can submit a malicious patch that ultimately plants an executable Git hook inside the repository, causing shell commands to run as the Gitea service account. Although the vulnerability nominally requires write access, Gitea's default open registration (no email confirmation) makes it effectively unauthenticated: an attacker simply registers an account, creates a repository, and self-triggers the exploit. NVD scores it CVSS 9.8 CRITICAL.

Affected Versions

Technical Details

The exploit abuses Git's three-way merge fallback. The attacker submits a patch through the diffpatch endpoint; submitting the same patch a second time triggers an add/add collision, and Git's merge machinery writes an attacker-controlled file into the repository's hooks/ directory (e.g. hooks/post-index-change). That file becomes an executable Git hook that Git runs — executing the attacker's shell commands as the Gitea OS/service account — the next time the index is updated. The whole chain is a single flow (register → create repository → send crafted patch), requires no user interaction, and is low-complexity. Gitea's fix changes the temporary clone used during patching from a bare repository to a non-bare one, so attacker-supplied paths can no longer be interpreted as executable hooks.

Discovery

The vulnerability was discovered and reported by security researcher Shai Rod (NightRang3r), with Gitea publishing advisory GHSA-rcr6-4jqh-j84m.

Exploitation Context

Exploitation is confirmed in the wild, and a public proof-of-concept exists. A widely-cited incident (documented by a developer on the Russian tech blog Habr) showed an automated scanner registering an account, creating a repository, and triggering the exploit within roughly 11 seconds, then dropping a cryptominer-style payload — one that cleared LD_PRELOAD/LD_LIBRARY_PATH, killed competing high-CPU processes, fetched architecture-specific binaries, and self-deleted, driving server CPU above 70%. Attacks have been observed over HTTPS against internet-exposed instances; the activity is opportunistic and automated rather than tied to a named threat actor. Large numbers of Gitea instances are reachable on the internet, making mass scanning attractive.

Remediation

1. Upgrade to Gitea 1.27.1 or later immediately — this is the primary fix.
2. Disable open self-registration ([service] DISABLE_REGISTRATION = true) or require email confirmation, so an anonymous attacker cannot obtain the write access the exploit needs.
3. Restrict internet exposure — place Gitea behind a VPN or reverse proxy with authentication where possible; there is little reason for most self-hosted instances to be openly reachable.
4. Hunt for compromise on any instance that was internet-exposed and unpatched: inspect repository hooks/ directories for unexpected executable hook files, review running processes for cryptominer activity and high CPU, and check for suspicious newly-registered accounts and repositories.
5. Rotate secrets (tokens, deploy keys, credentials stored on the host) if evidence of code execution is found.