Critical Gitea RCE Actively Exploited as Reported Attack Drops Miner-Like Payload

The investigation separated the confirmed vulnerability and CISA exploitation determination from the narrower claim that attackers deployed a cryptocurrency miner. Primary Gitea records established the affected range, access condition, execution mechanism and fixed version, while CISA independently confirmed exploitation in the wild. The administrator's incident evidence supports automated exploitation and delivery of a miner-like payload, but not attribution or definitive identification of the final malware.

1. What claims does the initial report make, and which require independent verification?
   Reviewed the supplied report for its timeline, vulnerability description, exploitation claim and alleged miner deployment.
   thehackernews.com ↗

   The report linked CVE-2026-60004, CISA's exploitation determination and a separately reported Gitea compromise involving a miner-like payload.

   why This framed two distinct questions: whether exploitation is confirmed generally and whether the reported payload was conclusively a cryptocurrency miner.

2. Has a government authority confirmed exploitation in the wild?
   Filtered CISA's Known Exploited Vulnerabilities catalog for CVE-2026-60004.
   cisa.gov ↗

   CISA lists the vulnerability as exploited in the wild, added it on 25 August 2026 and set a 28 August due date for affected federal bodies.

   why This independently supports confirmed active exploitation, but CISA supplies no actor, victim or campaign details.

3. What versions and permissions does the vendor identify?
   Read Gitea's primary security advisory.
   github.com ↗

   Versions from 1.17 up to but excluding 1.27.1 are affected; repository write access enables command execution as the Gitea service account, and open registration can provide that access to an external visitor.

   why This resolves the affected range and shows why nominal authentication does not protect a default-style publicly registering deployment.

4. When was the fix released and what version contains it?
   Reviewed Gitea's 1.27.1 release announcement.
   blog.gitea.com ↗

   Gitea released version 1.27.1 on 27 July 2026 with a fix for remote execution through diffpatch Git-hook installation.

   why This establishes the minimum patched version and shows that a vendor remedy pre-dated the public exploitation warning.

5. Does the formal vulnerability record corroborate the mechanism and severity?
   Opened the CVE Program record and checked its description, weakness classification and references.
   cve.org ↗

   The record describes remote code execution in Gitea before 1.27.1 through diffpatch Git-hook installation and classifies it as code injection with a critical 9.8 score.

   why This provides an additional authoritative record matching the vendor's technical account and fix boundary.

6. Is public exploit material available?
   Reviewed an independent public repository containing code for CVE-2026-60004.
   github.com ↗

   Public exploit code exists in addition to the proof of concept supplied with Gitea's advisory.

   why Defenders should expect the technical barrier to opportunistic scanning to be low, while recognising that code availability alone would not prove exploitation without the CISA listing and incident evidence.

7. What direct evidence supports the reported post-compromise activity?
   Read the affected administrator's incident report and examined its reconstructed request sequence and remediation account.
   habr.com ↗

   Logs from a Gitea 1.24.7 instance showed registration, private repository creation, repeated diffpatch requests, an execution-proof branch and a temporary file within about 11 seconds, followed by a loader and miner-like dropper. The author found no successful related SSH login or evidence of host-root access.

   why The artefacts credibly support automated exploitation over HTTPS and subsequent payload delivery, but the author's explicit evidential limits prevent firm malware attribution.

8. Can an independent security source corroborate exposure and remediation guidance?
   Reviewed runZero's vulnerability analysis and asset-discovery guidance.
   runzero.com ↗

   runZero identifies versions 1.17 through 1.27.0 as affected, notes the open-registration risk and recommends locating exposed installations and upgrading to 1.27.1 or later.

   why This independently corroborates the operational scope and supports prioritised inventory and patching actions.