Emerging Threat: (CVE-2026-60004) Gitea Remote Code Execution via ...

What is CVE-2026-60004?

CVE-2026-60004 is a code injection vulnerability in Gitea, the self-hosted Git service, that allows attacker-controlled patch content to be installed and executed as a Git hook on the server. The vulnerability carries a CVSS v3.1 base score of 9.8 (Critical) and is classified as CWE-94. Gitea published the advisory on July 28, 2026, crediting security researcher Shai Rod, who goes by NightRang3r, as the reporter.

The flaw sits in the POST /api/v1/repos/{owner}/{repo}/diffpatch endpoint. Gitea applies a submitted patch inside a shared bare temporary clone, invoking git apply with --index, --recount, --cached, and --binary, adding the -3 three-way fallback when the host runs Git 2.32 or later. Submitting the same patch twice produces an add/add collision, and the three-way fallback then checks the indexed path out to disk despite the --cached flag. Because the temporary clone is bare, its root is $GIT_DIR, so a file written to hooks/post-index-change lands in Git’s hook directory and becomes live. Git then executes it while writing the index.

Exploitation requires an account with write access to a repository. In a locked-down deployment that is a real barrier. Gitea’s default configuration is not locked down: it leaves registration open, requires neither email confirmation nor administrator approval, does not mark new accounts as restricted, and sets no repository creation limit. On an unmodified installation, an anonymous visitor can register an account, create a repository, and obtain the write access the exploit needs. That is why the CVSS vector records privileges required as none.

Successful exploitation runs commands as the Gitea operating system account. Depending on how the instance is isolated, the advisory notes this can expose app.ini and Gitea application secrets, process environment variables, mounted repositories, database credentials and contents, OAuth and integration credentials, and other internal or externally reachable services. Three further preconditions apply: Git 2.32 or later, an enabled diffpatch route, and a temporary filesystem that is both writable and executable. Common default deployments satisfy all three. A working proof of concept is published in the advisory and requires no outbound callback, since it stores command output in Git objects and retrieves it over authenticated smart HTTP.

What assets are affected by CVE-2026-60004?

Every Gitea release from 1.17 up to but not including 1.27.1 is affected. That range spans roughly four years of releases and covers the 1.23, 1.24, 1.25, and 1.26 lines that most self-hosted deployments are running today. Gitea stated on July 27, 2026, that Gitea Cloud instances would be upgraded automatically, so the exposure is concentrated in self-managed installations.

In practice, an affected asset is a self-hosted Git server sitting behind a reverse proxy on a standard HTTP or HTTPS port, or exposed directly on a non-default port such as TCP/3000. Gitea is popular precisely because it is small, fast, and simple to stand up, and that same property tends to place it outside central IT: deployed by an individual engineering team, by a contractor, on a spare cloud instance for one project, or inside an internal tooling stack that was never formally inventoried. The instances that matter most for this CVE are often the ones no one remembers owning.

Two deployment characteristics raise the stakes. The first is open registration, which is the shipped default and which converts an authenticated flaw into an unauthenticated one. The second is what a Git server holds: source code, CI credentials, deployment keys, signing material, and container images. Findings observed across the externally reachable Gitea assets in this set are consistent with that risk profile, including publicly enabled registration, user enumeration, unauthorized private container image access, and earlier Gitea access control issues. The preconditions this vulnerability depends on are not hypothetical.

What does our data show about exposure patterns?

Exposure in this set is led by Industrials at 23.4% of observed assets, with Health Care contributing 21.3%. Consumer Discretionary follows at 12.8%.

Industrials and Health Care share the operational conditions that produce this kind of exposure. Both run distributed estates assembled through acquisition and partner integration, both depend heavily on contracted and outsourced engineering, and both carry long decommission cycles on infrastructure that still works. A self-hosted Git server is the natural artifact of that environment: stood up for a specific integration, project, or vendor handoff, then left running after the work concluded. Health Care adds a second driver, in that clinical and device software teams frequently operate their own toolchains alongside central IT rather than inside it.

The largest single bucket in this set is Others at 42.6%, and most of that comes from assets whose owning organization could not be classified to a sector at all. That is the more telling finding. Assets that resist industry attribution are usually the same assets that resist ownership attribution: acquired infrastructure, orphaned subsidiary ranges, and cloud instances provisioned outside a managed account. A Gitea host in that category is unlikely to appear in a patch cycle, which matters more for this CVE than for most, because remediation here is a version upgrade that someone has to know to perform.

Are fixes available?

Yes. Gitea 1.27.1 shipped on July 27, 2026, and fixes the vulnerability. The change alters the temporary clone from bare to non-bare, which removes the condition that let a patched-in file land in the hook directory. Gitea Cloud instances were upgraded by the vendor. Upgrading to 1.27.1 is the only complete fix.

One caveat deserves attention from anyone tracking releases by changelog. The 1.27.1 release notes list the change under MISC as a patch-apply refactor rather than under SECURITY, and the security advisory did not follow until July 28, a day after the release. Teams that triage upgrades based on whether a release carries a security label would have had no reason to prioritize this one.

Disabling open registration is worth doing but is not a fix. It removes the anonymous account-creation path while an upgrade is scheduled, and it does nothing about existing users who already hold repository write access. As always, organizations should verify affected versions and fix availability directly with the vendor rather than relying on the presence or absence of a security tag in a changelog.

Are there any other recommended actions to take?

Until the upgrade is confirmed, defenders should:

• Inventory all Gitea instances, including developer-run and shadow deployments
• Disable open registration on every internet-facing Gitea instance
• Block the diffpatch API route at the reverse proxy or WAF layer
• Mount Gitea’s temporary directory noexec where the deployment permits it
• Audit repository write grants and revoke access no longer needed
• Monitor the Gitea host for unexpected child processes of the service account

How can CyCognito help your organization?

CyCognito published an Emerging Threat Advisory for CVE-2026-60004 in the CyCognito platform and is actively researching enhanced detection capabilities for this vulnerability.

To learn how CyCognito can help your organization reduce external exposure and manage emerging threats more effectively, contact us to request a demo.