Follow 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 originating from Gitea or its child processes
- – Unauthorized repository modifications
- – Unexpected access to application configuration, credentials, or secrets
The presence of these behaviors does not independently prove exploitation, but combinations such as new-account registration followed by repository creation, diffpatch requests, and new child processes should be investigated urgently.
Administrators should also review accounts created while the vulnerable version was exposed. Unknown users, repositories created shortly after registration, and accounts that immediately performed API operations may help identify exploitation attempts that occurred before the server was patched.
The CVE-2026-60004 mitigation process should go beyond installing version 1.27.1 if compromise is suspected. Because successful exploitation provides code execution with the privileges of the Gitea operating-system user, security teams should treat the affected host as potentially compromised and investigate accessible secrets and connected systems.
Incident responders should rotate database credentials, OAuth and API tokens, CI/CD secrets, SSH keys, deployment credentials, and other sensitive material accessible to Gitea where evidence suggests arbitrary code execution occurred. Private repositories should also be reviewed for unauthorized changes, and connected build or deployment systems should be examined for lateral movement.
CVE-2026-60004 demonstrates how a vulnerability in development infrastructure can rapidly evolve from a software bug into an active compromise path. With public exploit information available and confirmed exploitation underway, organizations running vulnerable self-hosted Gitea instances should prioritize both patching and retrospective threat hunting.
FAQ
What is CVE-2026-60004 and how does it work?
CVE-2026-60004 is a critical code injection vulnerability in Gitea’s diffpatch API. An attacker with repository write access can submit malicious patch content that results in an executable Git hook being installed and run, allowing arbitrary shell commands to execute as the Gitea operating-system user. Default open registration can allow an external attacker to obtain the required repository permissions by simply creating an account.
When was CVE-2026-60004 first discovered?
The exact private discovery date has not been publicly disclosed. Gitea credits security researcher Shai Rod, also known as NightRang3r, with reporting the issue. Version 1.27.1 containing the fix was released on July 27, 2026, and the security advisory was published on July 28. CISA confirmed active exploitation by adding the flaw to its KEV catalog on August 25.
What is the impact of CVE-2026-60004 on systems?
Successful exploitation allows arbitrary commands to run with the privileges of the Gitea service account. This can expose source-code repositories, application secrets, database credentials, OAuth material, CI/CD credentials, and other resources accessible from the compromised server. Attackers may also deploy malware or use the Gitea host as a foothold for further intrusion.
Can CVE-2026-60004 still affect me in 2026?
Yes. Any self-hosted Gitea installation running version 1.17 through 1.27.0 remains vulnerable. The risk is now particularly urgent because CISA has confirmed active exploitation, and at least one publicly described intrusion appears to have used the flaw to deploy a miner-like payload.
How can I protect myself from CVE-2026-60004?
Upgrade Gitea to version 1.27.1 or newer immediately. Disable open registration if it is not required, restrict repository creation and write access, and review historical API activity for suspicious diffpatch requests. If exploitation is suspected, investigate the host for malicious Git hooks and unexpected processes and rotate secrets accessible to the Gitea service account.
