CISA Confirms Gitea CVE-2026-60004 Exploited: Cryptominer Hits 5,000 Exposed Dev Servers

Attackers have planted cryptocurrency-mining malware on real development servers by exploiting CVE-2026-60004, a CVSS 9.8 code-injection flaw in Gitea — and the U.S. Cybersecurity and Infrastructure Security Agency confirmed the in-the-wild attacks on August 25 by adding the vulnerability to its Known Exploited Vulnerabilities catalog under Binding Operational Directive 26-04. Federal Civilian Executive Branch agencies must remediate all affected installations or discontinue use of the platform by August 28 — a 72-hour window that signals CISA’s assessment of the threat as critical and actively accelerating. A patch has been available since July 27; the month that elapsed before attackers were confirmed deploying malware is a documented failure of the self-hosted infrastructure patch cycle, not a deficiency in the patch released July 27.

The attack does not merely compromise a server. Because Gitea functions as the trust anchor for many organizations’ CI/CD build pipelines — the platform that stores source code and triggers automated builds — a successfully injected Git hook runs with the same service-account identity and permissions as every legitimate build trigger on the system. Any downstream build system that consumes Gitea’s hook events as authoritative build signals is also affected before patching occurs, which is the condition that makes a Git-infrastructure compromise categorically different from an ordinary server breach. An attacker who controls the build pipeline does not need to attack your production systems directly; they wait for your CI/CD system to deliver what they have placed into the build.

Cybersecurity watchdog Shadowserver tracks nearly 5,000 Gitea instances currently reachable from the public internet. The agency has not published how many of those remain unpatched, but a patch released a month before confirmed exploitation began — with a public proof-of-concept available from the day of the advisory — means the proportion still vulnerable is almost certainly substantial.

How Does Git Hook Injection Work in Gitea?

CVE-2026-60004 lives in Gitea’s diffpatch API endpoint — the internal interface that processes patch data for repository diffs. An authenticated user with repository write access can submit a specially crafted patch. The exploit works by submitting the same malicious patch twice in rapid succession, triggering what is called an "add/add collision" in Git’s three-way merge fallback logic. When Git’s fallback writes to disk to resolve the collision, the attacker-controlled file lands in the repository’s hooks/post-index-change directory — and Git fires that hook when it next updates the index. The hook executes arbitrary shell commands with the privileges of the Gitea service account on the host machine. The Gitea security advisory GHSA-rcr6-4jqh-j84m and the imbas007 proof-of-concept repository detail the full attack chain.

The vulnerability is classified as CWE-94 code injection weakness — Improper Control of Code Generation — the class of weakness in which attacker-controlled data crosses the boundary from the user-controlled data plane into the control plane. CWE-94 ranked among the top 18 most dangerous software weaknesses in 2024 and is associated with vulnerabilities in developer tooling that receive KEV designations at a disproportionate rate, because tooling sits upstream of multiple downstream systems.

The technical fix in Gitea v1.27.1 is precise: the temporary repository used for patch operations was changed from a bare clone to a non-bare clone with a working tree. In a non-bare repository, the hooks directory path is structurally separated from the content the patch operation writes to, so the attacker-controlled file cannot reach executable hook territory regardless of what the patch contains. SOC Prime’s analysis covers this fix mechanism in detail.

Security researcher Shai Rod (NightRang3r) of Salesforce discovered and reported the vulnerability to the Gitea maintainer team. The advisory published July 28, contained a public proof-of-concept. That decision accelerated attacker awareness considerably: a working PoC alongside the first disclosure is a compressed timeline for organizations that assume they have weeks after a patch before exploitation begins. The Hacker News first reported the confirmed exploitation after CISA’s KEV addition.

What Authenticated Really Means When Anyone Can Register

The "authenticated user with repository write access" framing of this vulnerability has created a false sense of insulation for some operators. In Gitea’s default configuration, open registration is enabled, email confirmation is not required, and newly registered users can create repositories immediately. An external attacker facing a default-configured, internet-facing Gitea instance needs to send one sign-up request, create one repository, and then execute the exploit. The "authenticated" threshold is functionally identical to no threshold at all.

That is the configuration a full-stack developer known online as Andrey (@Causelof) had running when their hosting provider, HOSTKEY, notified them that their virtual server had been consuming more than 70% of processor capacity in sustained violation of the service’s acceptable-use terms. The attackers had registered an account, created a repository, triggered the exploit chain through the diffpatch endpoint, written a "proof" of remote code execution back into a Git branch, then downloaded a universal shell-loader followed by a cryptocurrency-miner-like dropper that competed for CPU resources. Because the server ran Gitea inside Docker, execution occurred inside the container as the git user — the container boundary limited the blast radius in this specific incident, but it did not prevent the compromise. Help Net Security detailed the full attack chain from the Habr incident report.

Alibaba Cloud’s July 2026 security report documented the same attack pattern separately — exploitation of CVE-2026-60004 to install mining software — indicating that the campaign is automated, not individually targeted, and that it predates CISA’s KEV confirmation by more than three weeks.

Cryptomining is reliably the most visible and lowest-stakes use of compromised server infrastructure, not the ceiling. The same access path that installs a miner can install ransomware, a persistent backdoor, or source-code exfiltration tooling — without triggering a CPU alert that a hoster would notice.

Why Developer Infrastructure Is the Target, Not Just the Victim

Gitea occupies a specific position in an organization’s security architecture that makes compromising it disproportionately consequential. It is not a web application that processes user data; it is the platform that stores source code, manages code reviews, and — critically — often triggers CI/CD pipelines. BleepingComputer’s ongoing exploitation coverage documents that the campaign targeting Gitea continues.

An attacker with Gitea service-account access can read every repository on the instance, extract API keys and database credentials committed to git history (which never fully disappear even after deletion), modify CI/CD pipeline configurations, and reach SSH deploy keys and webhook endpoints that connect Gitea directly to live infrastructure. Because Git infrastructure is a trust anchor — build systems treat Gitea-sourced events as authoritative — code injected at the repository level propagates downstream before any signature or attestation check can catch it. The SolarWinds breach of 2020 demonstrated the damage ceiling for this class of attack on a government-scale target.

Software supply chain attacks exploit exactly this trust structure: the compromised element is not the target’s own systems but the trusted upstream tool that the target’s systems are designed to accept without question. CVE-2026-60004 provides the entry point into that upstream position.

This vulnerability affects all Gitea versions from 1.17 through 1.27.0 — essentially every deployment of a feature introduced years ago that was never specifically audited for this attack surface. RunZero’s vulnerability analysis provides guidance on finding exposed instances across an organization’s network. A historical parallel: CVE-2020-14144, the earlier hook-based remote code execution flaw in Gitea, exploited the same Git hook subsystem with the same authenticated-write-access entry condition. The NVD advisory for CVE-2020-14144 documents this recurrence. The recurrence is not coincidence — it reflects a structural feature of self-hosted Git platforms in which developer flexibility (the ability to configure custom hooks) and security (the assurance that hooks cannot be injected through the API) have never been fully reconciled.

What CISA’s Emergency Addition Changes

CISA’s Known Exploited Vulnerabilities catalog is not a predictive watch list. It requires three conditions before a vulnerability is added: a registered CVE identifier, clear remediation guidance, and independently confirmed evidence of in-the-wild exploitation. Adding CVE-2026-60004 on August 25 is a statement that CISA has confirmed real attacks in progress, not that it believes attacks are likely.

Under Binding Operational Directive 26-04 — the current framework governing vulnerability management for Federal Civilian Executive Branch agencies, which superseded BOD 22-01 in June 2026 — FCEB agencies are legally required to remediate all KEV-listed vulnerabilities by the specified deadline or discontinue use of the affected product. The CISA KEV alert sets August 28 as that deadline — three days from the catalog addition — CISA’s minimum remediation window and a signal that the agency’s internal threat intelligence assessed the active-exploitation risk as both confirmed and accelerating.

The pattern is not new to Gitea’s ecosystem. In January 2026, CISA added CVE-2025-8110 — a path-traversal flaw in Gogs, the platform from which Gitea was forked — to the CISA KEV catalog January 2026 after Wiz Research identified over 700 instances as compromised in what began as a zero-day campaign. In both cases, the common factors are the same: open-registration defaults, authenticated-but-low-barrier exploitation, self-hosted operator demographics without mandatory patch cycles, and a public exploit available before mass exploitation began.

How to Protect Your Organization Right Now

If your organization runs a self-hosted Gitea instance, three actions can close the primary exposure immediately:

Upgrade to Gitea v1.27.2 or later. Version 1.27.1 contains the CVE-2026-60004 fix; v1.27.2 is the current release and should be the target for organizations upgrading today. The Gitea blog publishes official release notes and download links. Gitea Cloud instances were automatically upgraded when v1.27.1 was released on July 27. On-premises operators must upgrade manually. Verify the running version using Gitea’s admin dashboard or the gitea --version command.

Disable open registration if your Gitea serves a defined user population. Open registration is the default setting that collapses the "authenticated user" exploit requirement to near-zero. For any instance serving an internal team or a known set of contributors, set DISABLE_REGISTRATION = true under the [service] section of Gitea’s app.ini configuration file and restart the service. Help Net Security’s mitigation guide covers additional configuration hardening steps. This does not replace patching — it closes the unauthenticated attack path while patching is scheduled.

Restrict network access. Gitea is developer infrastructure. It rarely requires anonymous public internet access. Place internet-facing instances behind a VPN or restrict access to documented IP ranges. Shadowserver’s visibility into nearly 5,000 exposed Gitea instances is a direct consequence of organizations leaving Git infrastructure open to arbitrary internet traffic. Network segmentation that prevents an attacker from reaching the instance at all is the most reliable mitigation available.

Additionally, audit existing Git hooks across all repositories for unauthorized or unexpected scripts. An instance that was internet-exposed with open registration enabled before patching should be treated as a potential incident-response case — not simply a patching exercise. Rotate all secrets accessible through the platform: database credentials, API keys, OAuth tokens, SSH deploy keys, and webhook configurations. Check recent commits to main and production branches for unauthorized modifications.

The exploit does not require an outbound callback channel to succeed, which means firewall egress rules and outbound proxy logs are insufficient alone to confirm whether an instance has been probed. WindowsForum’s security guidance recommends reviewing inbound access logs for unexpected POST requests to the /api/v1/repos/{owner}/{repo}/diffpatch endpoint, particularly from IP addresses not associated with your development team.

When Patch Availability and Patch Uptake Are a Month Apart

CVE-2026-60004 was disclosed, patched, and accompanied by a public proof-of-concept on July 27–28. Confirmed exploitation was documented in Alibaba Cloud’s July security report and corroborated by CISA on August 25 — a gap of nearly four weeks between a working exploit being publicly available and a government agency declaring active attacks confirmed.

That interval is the structural story underlying this incident. The organizations most likely to be running unpatched Gitea instances a month after a critical patch are small development teams, academic institutions, open-source projects, and smaller enterprises operating self-hosted infrastructure with lean IT resources — precisely the organizations that lack the automated patch enforcement, centralized vulnerability monitoring, and operational bandwidth to respond to security advisories within days. SecurityWeek’s reporting confirms unpatched-population security gaps — the population running self-hosted Gitea is also less likely to be running enterprise security monitoring that would detect a hook injection or a cryptominer before the hoster’s CPU-utilization alert fires.

The Gogs case from January 2026 made this explicit: over 700 instances were compromised before CISA’s KEV addition formalized the emergency. The Gitea case from now follows the same pattern one step later in the timeline — the KEV addition is earlier relative to the exploitation window, but the unpatched population is similarly characterized by operators who treat self-hosted Git infrastructure as permanent background infrastructure rather than a security perimeter requiring active management.

Self-hosted Git platforms are not peripheral to the software supply chain. They are, for many organizations, its origin point. Treating them with the same patch urgency applied to internet-facing web servers is not optional — it is the minimum necessary response to the threat model that CVE-2026-60004 has made concrete.

---

Frequently Asked Questions

How do I know if my Gitea instance is vulnerable to CVE-2026-60004?

Any Gitea installation running version 1.17 through 1.27.0 is vulnerable. Check your running version using the admin dashboard or the gitea --version command at the server. If the version is below 1.27.1, the instance is affected regardless of whether open registration is enabled. Open registration amplifies the risk by eliminating the need for a pre-existing account, but the vulnerability itself exists in the diffpatch API endpoint and can be exploited by any user with repository write access — including existing accounts. Upgrade to v1.27.1 or later (v1.27.2 is current as of August 27, 2026) and treat any instance that was internet-facing with open registration enabled as a potential compromise that warrants a full secret rotation and hook audit. The GitHub security advisory GHSA-rcr6-4jqh-j84m contains the official affected-version list.

What can attackers actually do after exploiting this flaw?

The exploit gives an attacker arbitrary shell command execution as the Gitea service account on the host machine. In practice, that access encompasses every repository on the instance — including git history, which routinely contains API keys, database credentials, and deploy tokens that were committed and later "deleted" but remain in history — all CI/CD pipeline configuration files, SSH deploy keys, webhook endpoints, OAuth credentials, and the Gitea main configuration file. An attacker who modifies CI/CD pipeline configuration or injects code into a monitored branch can reach every downstream system that consumes build artifacts from the compromised Gitea instance. Cryptomining is the most visible low-stakes use of that access; ransomware, persistent backdoors, and source-code tampering are the higher-impact payloads that require no additional privileges once the initial hook execution is established. Security Arsenal’s blast-radius analysis covers the full scope of post-exploitation impact.

Does this vulnerability affect Forgejo, the community fork of Gitea?

Forgejo shares code lineage with Gitea and should be evaluated for this vulnerability independently. Operators running Forgejo should check with Forgejo’s official security advisories for a specific advisory confirming which versions are affected and what the patched version is, rather than assuming Gitea’s v1.27.1 fix applies directly to Forgejo’s release train. The recommendation to disable open registration and restrict network access applies equally to Forgejo deployments regardless of patch status.

Why does a month go by between a patch release and confirmed attacks?

The gap reflects a structural property of self-hosted infrastructure: when no automatic update mechanism forces the upgrade, patch adoption depends entirely on operators actively monitoring security advisories, testing updates, and scheduling maintenance windows. The population of organizations running self-hosted Gitea — small teams, academic institutions, open-source projects — often lacks the dedicated security staff or automated patch tooling that enterprise environments mandate. A public proof-of-concept available from day one of the advisory means the attack barrier was low from July 28 onward; the month that followed represents the window during which unpatched instances that were already in the crosshairs became confirmed casualties. CISA’s KEV addition formalizes that the window has been open long enough to observe confirmed harm — not that it is just opening. BleepingComputer’s exploitation timeline report provides additional context.