Gitea CVE-2026-60004: Real-World Victim Reports CPU Spike and Dropper

A Russian system administrator recently published a detailed account on Habr of an attack against their Gitea instance exploiting CVE-2026-60004. Hosting provider HOSTKEY alerted them to persistently high CPU usage exceeding 70%. The case, reported by The Hacker News, provides a rare window into active exploitation with concrete operational impact: not just a theoretical breach, but provider throttling and a forensic investigation of a compromised server.

How the Vulnerability Works: diffpatch and Git Hook

CVE-2026-60004 is a Remote Code Execution flaw rated CVSS 9.8, present in Gitea from version 1.17 through 1.27.0 inclusive. The mechanism, documented by CISA, is precise: an attacker with repository write access sends a malicious patch to the diffpatch API endpoint, plants an executable Git hook, and achieves shell command execution with the privileges of the Gitea service account.

The severity lies not only in the technical mechanism but in the access path. Gitea's default configuration leaves registration open (DISABLE_REGISTRATION=false, REGISTER_EMAIL_CONFIRM=false), allowing an anonymous visitor to create an account with write access without any verification barrier. Victim Andrey/@Causelof explicitly linked this setting to the compromise: "The fact that open registration is enabled here is significant precisely because of its connection to the vulnerability."

The attack vector in the documented case was HTTPS, not exposed SSH. This detail matters for administrators who focus controls on non-standard ports or exposed services while overlooking ordinary web traffic.

"Gitea contains a code injection vulnerability that allows an attacker with repository write access to send a malicious patch to the diffpatch API endpoint to plant an executable Git hook and run shell commands as the Gitea service account" — CISA

The Victim's Account: From HOSTKEY Alert to Dropper

The chain of events began with an email from provider HOSTKEY reporting CPU usage above 70% on the victim's VPS. Andrey/@Causelof began analysis and identified a suspicious process exhibiting dropper behavior: fetching an architecture-specific payload, downloading it, writing it to disk, and executing it.

The description of this behavior — architecture-specific fetch, download, write, run — comes from the victim. The Hacker News characterized it as a "cryptocurrency-miner-like dropper," but that is a journalistic label, not an analytical confirmation. The same source reports that CISA has not disclosed exploitation-in-the-wild details nor attacker identities, and does not confirm a miner payload.

The central gap in the dossier is here: the exact nature of the next-stage payload is unverified. The victim explicitly stated: "I do not have confirmed information regarding the mining pool, wallet, miner family, or specific operator." The "miner-like" claim remains a subjective description based on the symptom (CPU spike), not code analysis.

What Is Verified and What Remains Unknown

The distinction between documented facts and blind spots is fundamental in this case. Confirmed elements: existence of the vulnerability with CVSS 9.8, presence since 2019 (version 1.17), patch available in 1.27.1, addition to CISA KEV catalog on August 25, 2026, HOSTKEY notification for CPU spike, vulnerable configuration identified, dropper behavior described in technical detail.

Unconfirmed elements: miner nature of the payload, attack objectives, operator identity, scale of exploitation beyond the single case, existence of public indicators of compromise, causal link between Andrey's attack and the CISA KEV addition. The Hacker News reports that CISA indicated it is "unclear" who is behind the attacks and what their real objectives are.

The dossier also does not specify targeted sectors, volumes of compromised instances, or provide usable IoCs for detection. The singularity of the source — a Habr post picked up by The Hacker News — demands caution in generalization: no infrastructural overlap emerges linking this specific case to broader campaigns at present.

Why This Matters

The brief does not document specific remedial measures indicated by the source. What makes this case relevant is the combination of three factors: a critical vulnerability with CVSS 9.8, a default configuration that exposes the attack to anyone, and measurable operational impact (provider throttling) that forced discovery of the intrusion.

The timeline is compressed: CISA added the vulnerability to the KEV catalog on August 25, 2026, with a patch deadline for U.S. federal agencies of August 28, 2026 — three days. This cadence reflects an active risk assessment, even absent public exploitation details.

The dossier does not specify whether patched version 1.27.1 also resolves configurations with open registration, nor whether disabling anonymous registration constitutes sufficient mitigation without patching. The source does not address these scenarios.

For administrators of self-hosted instances, the Andrey case serves as a barometer: the risk is not abstract, and discovery often comes via operational symptoms (billing, throttling, provider alerts) rather than active detection. The source does not document tools or methodologies for early detection.

Reading: The Default Settings Trap

The episode raises a structural issue in self-hosted software. Gitea, like many open-source platforms geared toward ease of adoption, enables features by default that become attack vectors in internet-exposed contexts. The combination of DISABLE_REGISTRATION=false and REGISTER_EMAIL_CONFIRM=false is not technically a vulnerability: it is a design choice that turns lethal in the presence of CVE-2026-60004.

This interaction between configuration and code is what makes the case interesting beyond the single incident. It is not just a flaw to patch, but an example of how onboarding conveniences can transform into attack surface when application code flaws emerge. The victim grasped this nexus; their technical analysis, within the limits of available information, is more sophisticated than many standard post-incident reactions.

The visibility problem remains open. Without the HOSTKEY notification, the attack could have persisted: the source does not indicate how much time elapsed between compromise and discovery, nor whether useful logs exist for forensic reconstruction. This silence is itself a data point.

Sources

• https://thehackernews.com/2026/08/critical-gitea-rce-actively-exploited.html

Information is based on the cited source and current as of publication.

Sources

• https://www.securityweek.com/cisa-warns-of-exploited-gitea-vulnerability/
• https://www.infosecurity-magazine.com/news/australia-exploitation-teamcity/
• https://www.news4hackers.com/cisa-issues-urgent-alert-gitea-security-flaw-exploited/
• https://www.cisa.gov/news-events/alerts/2026/08/25/cisa-adds-one-known-exploited-vulnerability-catalog
• https://podcast.securityweek.com/