CVE-2026-60004: Critical Gitea RCE Exploited to Deploy Miner-Like Payloads

A critical remote code execution vulnerability in Gitea has moved from disclosure to active exploitation less than a month after a patch became available. Tracked as CVE-2026-60004 and rated 9.8 on the CVSS scale, the flaw allows an attacker with ordinary repository write access to plant an executable Git hook and run arbitrary shell commands with the privileges of the Gitea service account.

On August 25, 2026, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) added the exploited Gitea vulnerability to its Known Exploited Vulnerabilities (KEV) catalog, confirming that attacks are occurring in the wild. Federal civilian agencies have been instructed to remediate affected installations by August 28, 2026.

The issue becomes particularly dangerous because Gitea enables open registration by default. Although exploitation technically requires an authenticated account with repository write permissions, an external attacker may be able to create an account, create a repository, and obtain those privileges without possessing any previously stolen credentials.

One publicly reported attack against a vulnerable server resulted in deployment of a dropper exhibiting cryptocurrency-mining behavior. The incident reinforces why the critical Gitea RCE actively exploited in the wild should be treated as an urgent remediation priority for internet-facing self-hosted development infrastructure.

CVE-2026-60004 analysis

The vulnerability is classified as CWE-94, Improper Control of Generation of Code, and resides in Gitea’s diffpatch functionality. The affected API endpoint applies user-supplied patches inside a temporary Git repository. Under vulnerable conditions, an attacker can manipulate this process so that repository-controlled content becomes an executable Git hook rather than an ordinary repository file.

The important details for CVE-2026-60004 center on how Gitea created the temporary repository used to process patches. Vulnerable releases used a bare Git clone, where the repository directory itself acts as Git’s internal data directory. Combined with Git’s patch-processing behavior, specially constructed repository content could therefore reach the hooks directory and become executable.

An attacker with write access can submit malicious patch content to the diffpatch API. By triggering a conflicting patch condition, Git’s three-way processing can cause an attacker-controlled executable file to be materialized as a post-index-change hook. Git subsequently executes that hook during repository operations, resulting in command execution as the operating-system account running Gitea.

CVE-2026-60004 affects Gitea 1.17 and later releases before version 1.27.1. Gitea 1.27.1, released on July 27, 2026, corrects the problem by changing the affected temporary clone from a bare repository to a non-bare repository, preventing attacker-controlled paths from being interpreted as executable Git hooks in the same manner.

Successful exploitation requires repository write access. However, Gitea’s default installation settings significantly weaken that prerequisite: registration is normally enabled, users do not necessarily need administrator approval or email verification, and newly registered users can create repositories. An attacker targeting an unchanged internet-facing installation may therefore be able to satisfy the required permissions simply by creating a new account.

Additional exploitation conditions identified in the technical research include a server-side Git version supporting the relevant three-way fallback behavior, access to the diffpatch endpoint, and a temporary filesystem where the Gitea service can write and execute files. These requirements mean not every vulnerable installation will necessarily be exploitable through exactly the same chain, but default configurations can provide a practical path.

Once arbitrary commands execute under the Gitea service account, the impact extends well beyond a single repository. Depending on how the environment is configured, an attacker may gain access to private repositories, database credentials, OAuth secrets, application configuration, environment variables, CI/CD credentials, package registries, or internal services reachable from the Gitea host.

For organizations using Gitea as part of software development and deployment workflows, this also creates a potential supply-chain risk. Compromise of a source-code management platform can expose proprietary code and deployment secrets and may provide opportunities to alter repositories or use stolen credentials to pivot into CI/CD and production infrastructure.

Security researcher Shai Rod, also known as NightRang3r, discovered and reported the vulnerability. Gitea released version 1.27.1 on July 27, followed by the formal security advisory on July 28. The issue initially had no confirmed exploitation reports, but that changed when CISA added it to the KEV catalog on August 25.

A public CVE-2026-60004 PoC has been available since the vulnerability’s disclosure, significantly reducing the effort required to understand and reproduce the underlying attack technique. Public security tooling has also added detection templates for vulnerable instances, increasing the likelihood that attackers can identify exposed servers at scale.

The Hacker News also documented a real-world incident involving an internet-facing Gitea server with open registration enabled. According to the administrator, the attacker reached the vulnerable service over HTTPS, created the conditions necessary for exploitation, and executed a dropper that consumed substantial CPU resources.

The dropper cleared certain library-related environment variables, searched for processes consuming significant CPU resources, attempted to terminate competing processes, downloaded a payload matching the host architecture, executed it, and then removed the downloaded file. The administrator did not recover enough evidence to identify a specific cryptocurrency miner, wallet, mining pool, or threat actor, so the payload should currently be described as miner-like rather than definitively attributed to a known cryptojacking family.

It remains unclear whether this specific attack caused CISA to add the vulnerability to KEV or whether the agency has observed separate exploitation campaigns. Neither CISA nor the two cited reports has publicly attributed the broader activity to a known threat actor.

No authoritative set of campaign-wide CVE-2026-60004 IOCs has been published. Defenders should therefore rely on behavioral evidence such as suspicious account creation, unusual calls to the diffpatch API, unexpected Git hooks, processes launched by the Gitea service, and anomalous CPU or outbound network activity.

CVE-2026-60004 Mitigation

Organizations running self-hosted Gitea should immediately upgrade to version 1.27.1 or later. Gitea Cloud environments were scheduled to receive the update automatically, while administrators of self-managed installations are responsible for applying the patched release themselves.

Because exploitation is now confirmed in the wild, patching should not be delayed until the next routine maintenance window. CISA’s KEV inclusion provides strong evidence that the vulnerability presents an immediate operational risk, with U.S. federal civilian agencies required to remediate it by August 28, 2026.

Organizations unable to patch immediately should disable public registration where it is not required. Setting registration to administrator-controlled mode prevents an unauthenticated internet user from simply creating an account and repository to obtain the write access necessary for the exploit. This measure reduces exposure but does not fix the vulnerability because existing users with repository write permissions can still reach the vulnerable functionality.

Administrators should additionally restrict repository creation and write permissions, reduce external access to Gitea where possible, and avoid exposing development infrastructure directly to the internet unless there is a clear business requirement.

CVE-2026-60004 detection should begin by identifying all Gitea installations, checking their exact versions, and determining whether public registration was enabled while the server was running an affected release. Internet-facing instances that allowed anonymous visitors to register accounts deserve the highest investigation priority.

To Detect CVE-2026-60004 exploitation attempts and post-compromise activity, defenders should review Gitea, API, operating-system, and network telemetry for:

• – Repeated or unexpected requests to /api/v1/repos/{owner}/{repo}/diffpatch
• – Newly created accounts followed quickly by repository creation and patch operations
• – Shells or unfamiliar processes spawned by the Gitea service account
• – Unusual sustained CPU utilization on Gitea hosts
• – Unexpected downloads or execution from temporary directories
• – New outbound connections originatin

Key Takeaways

• CVE-2026-60004 is a critical Gitea RCE vulnerability scored 9.8 CVSS that has moved from disclosure to active exploitation within a month.
• The flaw allows attackers with repository write access to plant executable payloads, making patching urgent for all Gitea instances.
• Gitea administrators should immediately update to the patched version and audit repositories for signs of exploitation activity.