Key Takeaways
- CISA has added CVE‑2026-60004 (CVSS 9.8) to its Known Exploited Vulnerabilities catalog after active exploitation was observed.
- The flaw is a remote‑code‑execution vulnerability in Gitea’s diffpatch endpoint that lets anyone with repository write access execute arbitrary shell commands as the Gitea OS user.
- Default Gitea installations allow open registration; an unauthenticated visitor can register, create a repository, obtain write permission, and trigger the exploit without pre‑existing credentials.
- The vulnerability affects all Gitea versions from 1.17 onward and was patched in 1.27.1; federal agencies must apply the fix by August 28, 2026.
- Security researcher Shai rod (NightRang3r) discovered and reported the issue.
- A real‑world attack observed by developer Andrey (@Causelof) used the flaw to drop a cryptocurrency‑miner‑like payload, causing sustained high CPU usage on a compromised VPS.
- The dropper performed typical evasion steps: clearing LD_PRELOAD/LD_LIBRARY_PATH, hunting high‑CPU processes, killing competitors, fetching an architecture‑specific payload, executing it, then deleting the file.
- The exact nature of the second‑stage payload (miner family, wallet, pool) remains unknown, but the CPU spike aligns with a cryptojacking campaign.
- Misconfigured settings such as DISABLE_REGISTRATION = false, REGISTER_EMAIL_CONFIRM = false, ENABLE_OPENID_SIGNUP = true, and REQUIRE_SIGNIN_VIEW = false enabled the attack vector.
- Organizations should disable open registration, enforce email confirmation, restrict sign‑up methods, and apply the latest Gitea patch promptly to mitigate risk.
Overview of the Vulnerability
The U.S. Cybersecurity and Infrastructure Security Agency (CISA) issued a warning on August 26, 2026, about active exploitation of a critical security flaw in Gitea tracked as CVE‑2026-60004 with a CVSS score of 9.8. The vulnerability resides in the diffpatch API endpoint, which processes repository diffs. An attacker who gains ordinary write access to a repository can send a specially crafted patch that plants an executable Git hook, thereby allowing arbitrary shell command execution under the Gitea service account. This level of access is sufficient to run any code the attacker chooses, making the flaw highly dangerous for exposed instances.
How Write Access Is Obtained
Although the diffpatch endpoint itself requires authentication and repository write permission, Gitea’s default configuration permits open registration. Consequently, an unauthenticated visitor can simply register a new account, create a repository, and instantly acquire the necessary write rights within that repository. No prior credentials or compromised accounts are needed; the attack chain begins with a public sign‑up form, making the vulnerability especially amenable to mass‑exploitation campaigns targeting publicly reachable Gitea servers.
Discovery and Patch Details
The issue was discovered and responsibly disclosed by security researcher Shai rod, known online as NightRang3r. According to Gitea’s advisory, the flaw affects all versions from 1.17.0 onward and was remedied in release 1.27.1. Organizations running any earlier version are urged to upgrade immediately. CISA’s addition of the vulnerability to its Known Exploited Vulnerabilities (KEV) catalog underscores the observed active use in the wild and triggers mandatory remediation timelines for federal agencies.
CISA’s KEV Entry and Federal Deadline
By placing CVE‑2026-60004 in the KEV catalog, CISA signals that the flaw is being exploited and that federal civilian agencies must prioritize patching. The directive requires that affected systems be updated by August 28, 2026, with agencies encouraged to adopt a risk‑based approach—prioritizing internet‑facing instances, those handling sensitive data, or systems lacking compensating controls. Non‑federal organizations are also advised to treat the vulnerability as high‑severity and apply the fix without delay.
Real‑World Exploitation Example
A concrete instance of the exploit was highlighted by full‑stack developer Andrey (@Causelof) in a post on the Russian platform Habr. Andrey reported that his personal Gitea instance, hosted on a VPS supplied by HOSTKEY, began consuming over 70 % of CPU capacity for an extended period, prompting the provider to throttle the virtual server’s resources. Investigation revealed that the spike originated from a malicious dropper that leveraged CVE‑2026-60004 to execute unauthorized code.
Attacker’s Initial Foothold
Andrey’s instance had the following settings enabled: DISABLE_REGISTRATION = false, REGISTER_EMAIL_CONFIRM = false, ENABLE_OPENID_SIGNUP = true, and REQUIRE_SIGNIN_VIEW = false. This configuration allowed anyone to sign up without email verification, use OpenID providers, and view content without authentication. With open registration active, an attacker registered a new account, created a repository, and obtained the write permissions needed to abuse the diffpatch endpoint—all over HTTPS, as SSH was not exposed.
Dropper’s Execution Flow
Before deploying the final payload, the dropper script performed a series of preparatory actions typical of stealthy malware: it cleared LD_PRELOAD and LD_LIBRARY_PATH to hinder library‑based defenses, searched for processes with high CPU usage, and attempted to kill competing processes that might interfere with its own execution. It then fetched a second‑stage binary appropriate to the host’s architecture, wrote it to disk, executed it, and finally deleted the file to reduce forensic traces. These steps suggest a sophisticated actor aiming to maintain persistence while minimizing detection.
Nature of the Second‑Stage Payload
Andrey noted that he did not analyze the contents of the downloaded payload, so the exact miner family, wallet address, mining pool, or threat actor remains unidentified. However, the sustained high CPU utilization is consistent with a cryptojacking operation, wherein the compromised host’s processing power is diverted to mine cryptocurrency for the attacker’s benefit. The absence of detailed payload analysis leaves open the possibility that the dropper could also deliver other malicious functionalities, such as remote access tools or data exfiltration modules.
Implications for Gitea Administrators
The incident underscores the danger of leaving default registration settings unchanged on publicly accessible Gitea deployments. Administrators should immediately disable open registration (set DISABLE_REGISTRATION = true), require email confirmation for new accounts (REGISTER_EMAIL_CONFIRM = true), consider disabling OpenID sign‑up unless strictly needed (ENABLE_OPENID_SIGNUP = false), and enforce authentication before any repository interaction (REQUIRE_SIGNIN_VIEW = true). These hardening steps, combined with timely application of the 1.27.1 patch, close the exploitation chain.
Broader Security Lessons
CVE‑2026-60004 exemplifies how a seemingly modest configuration oversight—allowing unrestricted user sign‑up—can elevate a medium‑privilege API flaw into a full‑blown remote code execution vector. Organizations must view authentication and registration controls as integral components of their attack surface, not mere convenience features. Regular configuration audits, principle‑of‑least‑privilege enforcement, and prompt vulnerability management remain essential defenses against similar threats in the future.
All information presented reflects publicly available disclosures up to August 26, 2026, and represents a concise synthesis of the reported events, technical details, and recommended mitigations.