Summary
- GHSA-rcr6-4jqh-j84m affects Gitea versions from 1.17 before 1.27.1 and was published on 28 July 2026.
- The flaw allows abuse of the diffpatch endpoint to install and execute a Git hook from repository-controlled content.
- Self-hosted code platforms hold repositories, secrets, tokens, and deployment paths, making exploitation a software supply chain and infrastructure risk.
Gitea has disclosed a critical remote code execution vulnerability that can allow an attacker with ordinary repository write access to execute shell commands as the Gitea operating-system user.
The vulnerability, published as GitHub Security Advisory GHSA-rcr6-4jqh-j84m, affects Gitea versions from 1.17 before 1.27.1. Gitea said its diffpatch endpoint can be abused to install and execute a Git hook from repository-controlled content. In deployments with default open registration, an unauthenticated visitor can obtain the required write access by registering an account and creating a repository.
The advisory describes a path through attacker-controlled patches in a shared bare temporary clone. Submitting the same patch twice can create an add/add collision, after which Git’s three-way fallback checks the indexed path out inside the bare clone. An executable entry named as a hook can then become live, and Git invokes the hook while writing the index.
Self-hosted code platforms are high-value systems because they sit close to software production. They may hold source code, deployment scripts, infrastructure definitions, issue discussions, access tokens, OAuth credentials, application secrets, and links into CI/CD environments. A compromise of the platform can reach far beyond the server process that was initially exploited.
The write-access condition still leaves meaningful exposure. Many engineering environments allow broad internal repository creation, guest collaboration, or self-service access. Where open registration is enabled, the attack path can be reached after account creation. Where registration is closed, a compromised low-privilege developer account may still provide the access needed to trigger the chain.
Git hooks are powerful by design because they execute scripts in response to repository events. If an attacker can manipulate a code-hosting platform into installing and executing a malicious hook, the boundary between repository content and server-side execution collapses. From there, the attacker may be able to inspect configuration, retrieve secrets, reach mounted repositories, or target connected build systems.
The issue is relevant to European public-sector suppliers, SaaS providers, industrial software vendors, research organisations, and engineering teams that self-host Git services for control, sovereignty, cost, or integration reasons. Those same reasons make patch management and configuration ownership more important.
Administrators should upgrade to Gitea 1.27.1, review registration settings, restrict repository creation where appropriate, and check for unexpected hooks, unusual repository activity, suspicious processes running as the Gitea user, and possible exposure of application secrets or CI/CD tokens. Code-hosting systems now sit on the path to business-critical releases and cloud deployments, so compromise can become a build-system, secret-management, and third party risk event at once.
