Gitea RCE CVE-2026-60004 Hits CISA KEV After Cryptojacking Attacks on Self-Hosted Git

What Happened

On August 25, 2026, CISA added CVE-2026-60004 to the Known Exploited Vulnerabilities catalog. The entry describes a code injection flaw in Gitea, the self-hosted Git service, that lets an attacker with repository write access send a crafted patchPatch🛡️A software update that fixes security vulnerabilities, bugs, or adds improvements to an existing program. to the diffpatch API endpoint, plant an executable Git hookGit Hook🛡️A script that Git executes automatically when a repository event occurs, such as a push, commit, or index write. Hooks are plain executable files in the repository's hooks directory and run with the privileges of the user running Git, which makes them a code-execution primitive on hosting servers., and run shell commands as the Gitea service accountService Account🛡️A non-human operating system or application account under which a service runs. Its permissions define the blast radius of any exploitExploit🛡️Code or technique that takes advantage of a vulnerability to cause unintended behavior, such as gaining unauthorized access. against that service, since attacker code executes with the service account's access to files, secrets, and the network.. The KEV record gives federal civilian agencies until August 28, 2026 to apply the vendor fix or stop using the product, under BOD 26-04. The catalog release that carried the entry was version 2026.08.25.

The bug is not new. Gitea shipped the fix in 1.27.1 on July 27, 2026, and the project published advisory GHSA-rcr6-4jqh-j84m the next day with a working proof-of-concept attached. Security researcher Shai Rod (NightRang3r) reported it. The advisory rates it CVSS 3.1 9.8 (Critical), vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, and classifies it as CWE-94, improper control of code generation.

What changed in the last week is evidence of in-the-wild abuse. A developer writing on Habr documented an automated attack on their own instance: a scanner registered an account, created a repository, fired the exploit, and executed a dropper as the git user inside the container. According to the Help Net Security summary of that write-up, the active phase lasted roughly 11 seconds and left no persistence, meaning no cron entries, systemd units, or added SSH keys. The Hacker News reported the dropper cleared LD_PRELOAD and LD_LIBRARY_PATH, killed competing processes, fetched an architecture-specific binary, and ran what looked like a cryptocurrency miner, pinning the VPS above 70% CPU until the hosting provider complained. SecurityWeek notes there were no public exploitation reports before CISA's warning, and the operator behind the campaign is unidentified.

Who Is Affected

Per the advisory, every Gitea release from 1.17 up to but not including 1.27.1 is vulnerable. That is roughly four years of releases. The fix landed in 1.27.1 via pull requests #38637 and #38638; Gitea 1.27.2, released August 14, is the current version and closes seven more CVEs on top of it, including a separate markup argument-injection RCE (CVE-2026-73539) and a token-scope bypass that let a write:user token add SSH keys (CVE-2026-73804). If you are still on 1.27.1, the upgrade path is not optional either.

The advisory lists four preconditions for exploitation: Git 2.32 or newer on the host, the diffpatch route enabled, a temporary filesystem that is both writable and executable, and an account with write access to a repository. That last item is the one that turns an authenticated bug into a practical unauthenticated one. Gitea's default configuration leaves registration open: DISABLE_REGISTRATION defaults to false, REGISTER_EMAIL_CONFIRM defaults to false, and ENABLE_OPENID_SIGNUP inherits the inverse of DISABLE_REGISTRATION. On an unmodified install, anyone who can reach the login page can create an account, create a repository, and immediately hold the only privilege the exploit needs. The attack on the Habr author's server followed exactly that sequence.

Internet-exposed instances with open registrationOpen Registration🛡️A configuration in which any visitor can create an account on a self-hosted service without admin approval. It converts authenticated-only vulnerabilities into effectively unauthenticated ones, because the attacker can create the account the exploit requires. are the population being hit right now. Internal instances are not safe by default either: any contractor, intern, or compromised developer account with write access to a single repository can execute code on the server.

Technical Analysis

The vulnerable code is in services/repository/files/patch.go. When a client calls POST /api/v1/repos/{owner}/{repo}/diffpatch, Gitea applies the supplied patch inside a shared bare temporary clone using git apply with the --cached flag, and on Git 2.32 or later adds the -3 three-way fallback. The --cached flag is supposed to confine the operation to the index and never touch the working tree.

The trick is submitting the same patch twice. The second application produces an add/add collision, and Git's three-way fallback resolves it by checking the indexed path out to disk, ignoring --cached. Because the temporary repository is bare, its root is $GIT_DIR, so a patch that adds an executable file at hooks/post-index-change writes straight into Git's hook directory. Git runs post-index-change whenever it writes the index, which is exactly what the apply operation does next. The hook executes as the Gitea service account. Its exit status never appears in the diffpatch response, so the API returns nothing suspicious to the caller and nothing obvious to the logs.

The published proof-of-concept avoids outbound network entirely. It captures command output into Git objects, creates a branch containing the results, and fetches that branch over authenticated Smart HTTP. Egress filtering alone will not stop a data-theft variant; it only slows the miner variant observed so far.

The blast radius is whatever the service account can reach. The advisory calls out app.ini and the secrets inside it, environment variables holding credentials, every mounted repository, the database, and any OAuthOAuth🛡️An open standard authorization protocol that allows applications to access user resources without exposing passwords, using tokens instead of credentials. or integration tokens stored on the instance. For a lot of shops that means CI runner tokens, deploy keys, and the source of every internal application. Understanding why git hooks are a server-side attack surface explains why this class of bug keeps recurring across forge software.

Immediate Actions

1. Upgrade to Gitea 1.27.2. It contains the CVE-2026-60004 fix from 1.27.1 plus the August security batch. Gitea's release notes for both versions say to upgrade as soon as possible; the KEV deadline for federal agencies is August 28, and the same three-day window is a reasonable bar for everyone else given a public PoC and confirmed exploitation.
2. Close open registration until the upgrade is done. Set DISABLE_REGISTRATION to true in app.ini (custom/conf/app.ini, or /etc/gitea/conf/app.ini on package installs), and consider REQUIRE_SIGNIN_VIEW to keep the API away from anonymous users. Gitea's documentation states a full restart is required for configuration changes to take effect. This does not fix the flaw; it removes the free write-access path an outsider needs. Anyone already holding an account with write permission can still exploit an unpatched instance.
3. Audit accounts and repositories created since late July. The observed campaign creates a throwaway user and a throwaway repository. Unfamiliar accounts, repositories with a single odd commit, or branches you did not create are the fingerprint.
4. Hunt for the miner. Look at CPU history, processes owned by the Gitea service user, and outbound connections from the host or container. The Habr case showed high CPU load as the first symptom.
5. Assume secrets are burned if you find any indicator. Rotate database credentials, the secrets in app.ini, OAuth client secrets, runner registration tokens, and deploy keys. The developer whose instance was hit rotated secrets and tokens, removed extra signup methods, tightened Docker networking, and blocked outbound internet from the container. A structured post-compromise checklist for self-hosted services covers the order of operations.
6. Note that DISABLE_GIT_HOOKS, which defaults to true, governs the user-facing custom hooks feature. It is not documented as a mitigation for this bug, which writes hooks through a different path. Do not treat it as protection.

Long-Term Outlook

This is the second Gitea RCE in a month and the second security batch in three weeks. Self-hosted developer platforms hold source code, CI credentials, and deploy access, and they are increasingly run by small teams on a single VPS with default settings. The scanner that hit the Habr author's instance did not care who they were; it cared that registration was open and the version string was old. Hardening a self-hosted Git server means treating registration, network egress, and the service account's reach as security controls, not conveniences.

Expect the cryptojackingCryptojacking🛡️Unauthorized use of a compromised system's CPU or GPU to mine cryptocurrency for the attacker. Typically delivered by an automated dropper after an exploit, it is usually detected through sustained high CPU load rather than through data loss. crews to be followed by operators who read the PoC more carefully. A hook that exfiltrates app.ini and every repository through an authenticated Git fetch is quieter than a miner and far more valuable. If your instance was exposed and unpatched between July 28 and now, the honest baseline is to treat its secrets as compromised and rebuild from a known-good state. For triage cadence, the procedure in how to triage a CISA KEVCISA KEV🛡️The Known Exploited Vulnerabilities catalog maintained by CISA, listing vulnerabilities actively exploited in attacks that federal agencies must patch by specific deadlines. addition in 72 hours applies directly: confirm exposure, patch, hunt, rotate.

Sources

• CISA Known Exploited Vulnerabilities catalog feed (catalog version 2026.08.25): https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json
• Gitea security advisory GHSA-rcr6-4jqh-j84m: https://github.com/go-gitea/gitea/security/advisories/GHSA-rcr6-4jqh-j84m
• Gitea 1.27.1 release notes: https://blog.gitea.com/release-of-1.27.1/
• Gitea 1.27.2 release notes: https://blog.gitea.com/release-of-1.27.2/
• Gitea configuration cheat sheet: https://docs.gitea.com/administration/config-cheat-sheet
• The Hacker News, Critical Gitea RCE actively exploitedActively Exploited🛡️A vulnerabilityVulnerability🛡️A weakness in software, hardware, or processes that can be exploited by attackers to gain unauthorized access or cause harm. that attackers are currently using in real-world attacks, requiring immediate patching regardless of severity score.: https://thehackernews.com/2026/08/critical-gitea-rce-actively-exploited.html
• The Hacker News, original disclosure coverage (July 29): https://thehackernews.com/2026/07/new-gitea-rce-lets-repository-writers.html
• Help Net Security: https://www.helpnetsecurity.com/2026/08/26/gitea-cve-2026-60004-exploited-in-the-wild/
• SecurityWeek: https://www.securityweek.com/cisa-warns-of-exploited-gitea-vulnerability/