A critical remote code execution vulnerability in Gitea — rated CVSS 9.8 — allows a user with ordinary repository write access to execute arbitrary shell commands on the server hosting the Gitea instance. CVE-2026-60004 affects all Gitea releases from version 1.17 through 1.27.0 and was patched in version 1.27.1. No evidence of active exploitation has been reported as of July 29, 2026, but the severity and breadth of the affected version range make this a priority patch for every organization running a self-hosted Gitea deployment.
How CVE-2026-60004 Converts Patch Content into a Live Shell Command
The vulnerability stems from how Gitea processes incoming patches during merge operations. Gitea does not adequately sanitize or restrict what can be written into Git hook files when processing attacker-controlled patch content. A user with ordinary repository write access — a contractor, a junior developer, or any compromised account with push rights — can craft a patch payload that gets written into a Git hook file. When the hook triggers, Gitea executes the embedded shell commands under the Gitea service account.
Git hooks are scripts that run automatically in response to specific Git events: pre-receive, post-receive, update, and others. In a properly secured Git server, hook content should be controlled exclusively by administrators. CVE-2026-60004 collapses that boundary, placing hook-writing capability in the hands of any repository writer.
What an Attacker with Repository Write Access Can Now Reach
The Gitea service account typically has read access to every repository on the instance, along with access to the server’s file system, environment variables, and any secrets stored in repository configuration. An attacker who achieves shell execution as the service account can read the SSH keys used for repository authentication, exfiltrate credentials stored in .gitconfig or repository-level secrets, access every repository hosted on the server regardless of visibility settings, and modify or poison the codebases of any project the service account can reach.
In organizations that connect Gitea to CI/CD pipelines, the service account often holds tokens or credentials for downstream build systems, artifact registries, and deployment targets. Shell access to the Gitea server can translate to access across the entire connected deployment chain.
Self-Hosted Gitea and the Insider Threat Surface
Gitea is widely deployed as a self-hosted alternative to GitHub and GitLab by organizations seeking to keep source code on internal infrastructure. That deployment pattern creates a concentrated risk: a single vulnerable server often hosts all internal repositories across development teams, including codebases for production services, internal tooling, and sensitive configuration-as-code.
Why the Write-Access Attack Vector Is Particularly Dangerous
CVE-2026-60004’s attack vector — ordinary repository write access — is available to a broader population than typical privilege-escalation vulnerabilities that require administrative or local system access. Contractors commonly hold repository write access to deliver project contributions. External open-source contributors may hold write access to specific branches. Any of these accounts, if compromised or acting maliciously, represents a direct path to server-level shell execution.
The threat is distinct from vulnerabilities that require pre-existing administrative access, which generally limits the attacker population to those who have already achieved significant privilege. Here, the barrier is write access to any single repository on the instance.
Patch Availability and Upgrade Path
Gitea released version 1.27.1 as the fix for CVE-2026-60004. Organizations should identify all self-hosted Gitea instances running versions 1.17 through 1.27.0 and upgrade immediately. In environments where an immediate upgrade is not possible, restricting repository write access to the smallest possible set of accounts — and auditing current write-access grants — reduces the effective attack surface while the patch is staged.
The absence of confirmed active exploitation at the time of disclosure provides a narrow window for remediation before the vulnerability’s CVSS 9.8 score and detailed public disclosure attract attacker attention. Historically, critical RCE vulnerabilities in widely deployed self-hosted Git platforms have drawn exploitation attempts within days to weeks of public disclosure, particularly when the attack vector requires no special privilege beyond standard developer access. Organizations with multiple Gitea instances should audit all of them, not only the primary production deployment, since development, staging, and mirror instances often run older versions and hold access credentials to the same downstream systems as production.
