Your Gitea instance just served cryptojacking malware to an attacker who never should have had access. This isn't hypothetical. CVE-2026-60004, a remote code execution vulnerability with a CVSS score of 9.8, is being actively exploited to deploy mining payloads. CISA added it to their Known Exploited Vulnerabilities catalog, and federal agencies have until August 28, 2026, to patch.
Here's what went wrong, what the standards require, and what you need to fix today.
What Happened
Attackers exploited CVE-2026-60004 in Gitea, a lightweight self-hosted Git service. The vulnerability affects all versions from 1.17 onward and allows anyone with write access to execute arbitrary shell commands through a specially crafted Git operation. The attack chain is straightforward: gain write access (often through open registration), push malicious content, trigger the RCE, and deploy cryptojacking payload.
The problem? Many Gitea instances run with default configurations that enable open registration. An attacker doesn't need to compromise credentials, they just sign up.
Timeline
Initial Discovery: The vulnerability was identified in Gitea's handling of Git hooks and repository operations.
Patch Release: Version 1.27.1 shipped with a fix, addressing the command injection flaw.
Active Exploitation: Security researchers observed in-the-wild attacks deploying cryptocurrency miners. Attackers targeted internet-facing Gitea instances, created accounts where registration was open, and used write permissions to trigger the RCE.
CISA Warning: The vulnerability was added to the Known Exploited Vulnerabilities catalog with a mandatory remediation deadline for federal agencies.
Ongoing Campaign: Exploitation continues against unpatched instances, particularly those with default settings intact.
Which Controls Failed or Were Missing
Configuration Management: Default settings left registration open to anyone. No one reviewed whether public registration made sense for an internal code repository.
Access Control: The system granted write permissions too broadly. Even if registration needed to be open (it probably didn't), write access should have required approval.
Vulnerability Management: Patching didn't happen fast enough. Version 1.27.1 existed, but many instances remained on vulnerable versions.
Asset Inventory: Teams didn't know where all their Gitea instances were running. Shadow IT and departmental deployments fell outside the patch cycle.
Change Detection: No one noticed when CPU usage spiked or when unknown processes started consuming resources. The cryptominer ran until someone investigated performance degradation.
What the Relevant Standards Require
NIST 800-53 Rev 5 calls this out explicitly. Control CM-7 (Least Functionality) requires you to disable or restrict functions, ports, protocols, and services that aren't needed. Open registration on an internal Git server violates this principle. Control CM-6 (Configuration Settings) mandates documented configuration baselines and regular reviews. "We installed it with defaults" isn't a baseline.
ISO 27001 addresses this in Annex A.8.9 (Configuration Management). You're required to establish and document security configurations for all systems. The standard expects you to review configurations when threats change, and a 9.8 CVSS vulnerability counts as a threat change.
PCI DSS v4.0.1 Requirement 6.3.1 demands that security vulnerabilities are identified and addressed based on risk ranking. A critical RCE being actively exploited sits at the top of your risk ranking. Requirement 2.2.1 requires hardening configurations before deployment. Default settings don't meet this bar.
SOC 2 Trust Service Criteria CC6.6 and CC6.7 cover logical and physical access controls. If your Gitea instance stores customer code or data, open registration fails both controls. Your auditor will ask how you prevent unauthorized access, "we didn't change the defaults" won't pass.
The federal deadline (August 28, 2026) comes from Binding Operational Directive 22-01, which requires agencies to patch KEV catalog vulnerabilities within prescribed timeframes. If you're not a federal agency, you don't have a BOD deadline, but you do have compliance obligations that demand the same urgency.
Lessons and Action Items for Your Team
Audit every Gitea instance today. Run a network scan for port 3000 (Gitea's default) and port 22 (SSH). Check cloud environments, departmental servers, and developer workstations. You can't patch what you don't know exists.
Review registration settings immediately. Disable open registration unless you have a documented business requirement. If you need external contributors, use invite-only workflows or federated authentication. This applies to all self-hosted tools, not just Gitea.
Patch to version 1.27.1 or later. Test in staging first, but don't let testing become an excuse for delay. A critical RCE with active exploitation gets a 72-hour patch window, not a 30-day change control cycle.
Implement configuration baselines. Document the security settings for every category of system you deploy. Your baseline should explicitly disable features like open registration, require authentication for read access, and enforce least-privilege permissions. Store these baselines in version control and review them quarterly.
Set up resource monitoring. Cryptojackers max out CPU. Configure alerts for sustained high CPU usage, unexpected processes, and unusual network connections. This won't prevent exploitation, but it'll shorten your detection window from weeks to hours.
Map your Git infrastructure to data classification. If your Gitea instance stores customer data, payment card information, or regulated content, it inherits those compliance requirements. Open registration and unpatched critical vulnerabilities fail every relevant control.
Review your vulnerability management SLAs. If your current process wouldn't have caught and patched this within the federal deadline, your SLAs are too slow. Critical vulnerabilities with active exploitation need 48-72 hour remediation, not 30 days.
Test your incident response. When the next cryptojacking payload hits, can your team identify the entry point, contain the instance, and determine what data was exposed? Run a tabletop exercise using this Gitea scenario.
The pattern here isn't unique to Gitea. Default configurations, delayed patching, and missing asset inventory create the same exposure in Grafana, Jenkins, GitLab, and dozens of other self-hosted tools. Fix those problems for Gitea, and you'll prevent the next incident before it starts.
