Gitea RCE Under Active Exploitation: CVE-2026-60004

Key Takeaways

A critical remote code execution vulnerability in Gitea, the open-source, self-hosted Git hosting platform, is now under confirmed active exploitation and has been added to CISA’s Known Exploited Vulnerabilities (KEV) catalog with a federal patching deadline of August 28, 2026 [1][2][10]. CVE-2026-60004 carries a CVSS score of 9.8 and allows any user with write access to a repository — including unauthenticated attackers who self-register on instances that permit open sign-up, Gitea’s default configuration — to plant a malicious Git hook via the platform’s diffpatch API endpoint and execute arbitrary shell commands as the Gitea service account [1][3]. Gitea shipped a fix in version 1.27.1 on July 27, 2026, roughly a month before CISA confirmed exploitation in the wild, underscoring how quickly attackers weaponized a disclosed vulnerability against unpatched, internet-facing instances that remained exposed well after the fix was available [4][5]. Documented attacks have deployed cryptocurrency-mining droppers that consume CPU resources, but the same access path could just as easily be used for source code theft, credential harvesting, or supply chain tampering given the sensitivity of what a Git server typically holds [2][3]. Organizations running self-hosted Gitea should treat this as an emergency patching event rather than routine maintenance, and should assume that any exposed, unpatched instance may already be compromised.

Background

Gitea is a lightweight, self-hosted Git service used by organizations that want the collaborative features of GitHub or GitLab without ceding control of their source code to a third-party cloud provider. That self-hosting model is commonly cited as appealing to cost-conscious teams, government agencies, and organizations in regulated or resource-constrained environments, though Gitea does not publish independently verified adoption figures by sector; what is clear is that self-hosting shifts patching responsibility entirely onto the operator rather than a managed platform vendor. Security researcher Shai Rod (NightRang3r) reported CVE-2026-60004 to the Gitea maintainers, who published a security advisory and released the fixed version, 1.27.1, on July 27, 2026 [4][6]. The vulnerability affects every Gitea release from 1.17 through 1.27.0, a span covering several years of production deployments [1].

The flaw lives in the POST /api/v1/repos/{owner}/{repo}/diffpatch API endpoint, which Gitea exposes to let repository collaborators apply patches programmatically. An attacker can submit the same patch twice to force an “add/add” merge collision; when Gitea processes that collision using Git’s three-way merge fallback on Git 2.32 or later, Git checks out the indexed path even though the operation was invoked with the --cached flag [4]. Because the temporary clone Gitea creates for this operation is a bare repository, its working root is effectively $GIT_DIR — the repository’s internal Git directory — so a file placed at the path hooks/post-index-change lands directly inside Git’s hook directory instead of a harmless working copy. Git then executes that file automatically as part of its own indexing process, running it with the privileges of the Gitea service account [4]. Exploitation requires only ordinary write access to a repository, a bar that open self-registration — Gitea’s out-of-the-box setting — reduces to nothing at all: an attacker can register an account, create a repository, and trigger the exploit chain in roughly the time it takes to run a script [3].

CVE-2026-60004 is one of the most consequential Gitea vulnerabilities to draw public attention in 2026, following CVE-2026-27771, disclosed earlier in the year, a missing-authorization defect that let unauthenticated users pull “private” container images from Gitea’s built-in registry for approximately four years before discovery [7]. Taken together, the two incidents suggest a pattern worth naming: Gitea’s rapid feature growth — container registry, patch API, hook automation — may be outpacing the access-control and input-handling scrutiny those features need, and each defect has affected a substantial installed base of self-hosted, often lightly monitored, instances. The table below summarizes how the two disclosures compare.

The two vulnerabilities differ in root cause and mechanism, but both trace back to the same underlying operational reality: Gitea instances are frequently deployed with default settings on internet-facing infrastructure, and the population of operators who patch promptly appears to lag well behind the population of instances that remain exposed.

Security Analysis

The practical severity of CVE-2026-60004 comes from the combination of a low exploitation bar and a high-value target. Git servers are, by design, repositories of an organization’s most sensitive engineering assets: proprietary source code, embedded credentials and API tokens, CI/CD pipeline configuration, infrastructure-as-code definitions, and often direct network access to build and deployment systems. Gaining code execution as the Gitea OS user does not require lateral movement to reach much of that material; on many deployments, the service account itself can read repository contents, environment variables, and any secrets mounted into the Gitea process or its host [4]. Security researchers characterize the realistic blast radius as including application and environment secrets, database credentials, OAuth tokens, and any internal services reachable from the compromised host [4].

Reported exploitation to date has centered on opportunistic cryptomining rather than targeted intrusion. One documented incident began when a Gitea operator noticed anomalous CPU utilization and traced it to a compromise: an automated actor registered an account, created a repository, and completed the exploit chain to download and execute an architecture-appropriate cryptocurrency-mining dropper, reportedly within about eleven seconds of initial contact [2][3]. The dropper cleared environment variables, terminated competing processes — a common technique for crowding out rival miners on the same host — fetched a payload matched to the system’s CPU architecture, and executed it to consume available compute resources [1]. The speed and automation of this attack indicate that adversaries are scanning for and exploiting exposed Gitea instances at scale rather than conducting manual, targeted operations, which is consistent with how opportunistic cryptomining campaigns typically behave against newly disclosed vulnerabilities.

The cryptomining activity observed so far should be read as a floor, not a ceiling, on the risk this vulnerability poses. An attacker with arbitrary shell execution as the Gitea service account has the same access needed for far more damaging outcomes: exfiltrating proprietary source code, harvesting CI/CD secrets to pivot into build and release infrastructure, or planting backdoors in code before it is committed or reviewed. Because the exploit runs through a legitimate-looking API call rather than an obvious binary exploit, and because many self-hosted Gitea deployments run with limited logging or monitoring compared to managed SaaS alternatives, an operator may have no clear signal that anything beyond elevated CPU usage occurred, particularly if an attacker chose to move quietly rather than run a resource-hungry miner. Endpoint-scanning vendor Shadowserver tracks roughly 5,000 internet-exposed Gitea instances of undetermined patch status, giving a rough sense of the population still potentially at risk as of late August 2026 [2].

CISA’s decision to add CVE-2026-60004 to its Known Exploited Vulnerabilities catalog on August 25, 2026, with a three-day remediation deadline for federal civilian agencies, reflects the agency’s assessment that active, real-world exploitation is underway and that the risk warrants expedited action beyond routine patch cycles [1][2][5][10]. That designation, while binding only on U.S. federal agencies, is widely treated across the security community as a strong signal that any organization running the affected software should prioritize remediation immediately rather than folding it into a normal patch window.

Recommendations

Immediate Actions

Organizations running self-hosted Gitea should confirm their deployed version and upgrade to 1.27.1 or later without delay; Gitea’s maintainers have since released 1.27.2, which also contains the fix and is the currently recommended target version [1][8]. Where immediate patching is not feasible, operators should disable open self-registration and restrict repository write access to trusted, authenticated users only, since the exploit requires write access that anonymous sign-up otherwise grants for free. Instances that are internet-facing and cannot be patched or reconfigured quickly should be temporarily placed behind a VPN, reverse proxy with authentication, or otherwise removed from public exposure until the upgrade is complete.

Short-Term Mitigations

Once patched, operators should audit their environment for signs of prior compromise rather than assuming the upgrade alone resolves any exposure that occurred before it was applied. This includes reviewing process lists and scheduled tasks for unrecognized cryptomining binaries or unusual CPU consumption patterns, checking repository hook directories for unauthorized post-index-change or similar hook files, examining recent account registrations and repository creation events for anomalous automated activity, and rotating any credentials or secrets that were accessible to the Gitea service account during the vulnerable window. Because the documented attack pattern relies on automated scanning and rapid exploitation, organizations should treat any unpatched instance that has been internet-facing since late July 2026 as potentially compromised until log review proves otherwise.

Strategic Considerations

The recurrence of serious vulnerabilities in Gitea’s API surface — first the container registry authorization gap in CVE-2026-27771, now the diffpatch hook-planting flaw in CVE-2026-60004 — argues for treating self-hosted developer tooling as Tier-1 infrastructure within vulnerability management programs rather than as background utility software. That means subjecting Git servers to the same patch-SLA discipline, exposure monitoring, and least-privilege configuration review applied to production application infrastructure, disabling open registration by default unless there is a specific business need for it, and building monitoring capable of detecting anomalous repository or hook activity rather than relying solely on host-level resource alerts. CSA’s AI Controls Matrix (AICM) Application & Interface Security and Threat & Vulnerability Management domains provide a structured basis for this kind of ongoing scrutiny of self-hosted source code management platforms.

CSA Resource Alignment

This incident connects directly to CSA’s prior analysis of Gitea CVE-2026-27771: Private Container Registry Exposure, published earlier in 2026, which examined a separate missing-authorization defect in Gitea’s container registry that exposed private images to anonymous pulls for approximately four years [7]. That report’s central recommendation — treating self-hosted Gitea/Forgejo deployments as Tier-1 assets subject to the same patch-management rigor, access logging, and secret-rotation discipline as production application infrastructure — applies with equal force to CVE-2026-60004, and the two advisories together illustrate a recurring pattern of access-control and input-handling defects in Gitea’s rapidly expanded API surface that operators should factor into their platform risk assessments.

More broadly, this incident falls within the Application & Interface Security (AIS) and Threat & Vulnerability Management (TVM) domains of CSA’s AI Controls Matrix (AICM) v1.1, which provide structured control objectives for API-endpoint authorization, secure software development, and timely vulnerability remediation applicable to self-hosted developer tooling [9]. Organizations mapping their response to CVE-2026-60004 into a governance or compliance narrative can reference AICM’s TVM controls for patch-SLA enforcement and its AIS controls for API access-control review as the relevant framework anchors.

References

[1] The Hacker News. “Critical Gitea RCE Actively Exploited as Reported Attack Drops Miner-Like Payload.” The Hacker News, August 26, 2026.

[2] BleepingComputer. “Hackers Now Exploit Critical Gitea Flaw in Code Injection Attacks.” BleepingComputer, August 26, 2026.

[3] Help Net Security. “Critical Gitea Vulnerability Now Exploited in the Wild (CVE-2026-60004).” Help Net Security, August 26, 2026.

[4] The Hacker News. “New Gitea RCE Lets Repository Writers Plant a Git Hook to Run Shell Commands.” The Hacker News, July 2026.

[5] SecurityWeek. “CISA Warns of Exploited Gitea Vulnerability.” SecurityWeek, August 2026.

[6] Gitea. “Gitea 1.27.1 Is Released.” Gitea Blog, July 27, 2026.

[7] Cloud Security Alliance. “Gitea CVE-2026-27771: Private Container Registry Exposure.” Cloud Security Alliance, 2026.

[8] runZero. “Gitea Vulnerability CVE-2026-60004: Find Impacted Assets.” runZero Blog, 2026.

[9] Cloud Security Alliance. “AI Controls Matrix (AICM) v1.1.” Cloud Security Alliance, 2026.

[10] Cybersecurity and Infrastructure Security Agency. “CISA Adds One Known Exploited Vulnerability to Catalog.” CISA, August 25, 2026.