Full Report
The developers of Rspack have revealed that two of their npm packages, @rspack/core and @rspack/cli, were compromised in a software supply chain attack that allowed a malicious actor to publish malicious versions to the official package registry with cryptocurrency mining malware. Following the discovery, versions 1.1.7 of both libraries have been unpublished from the npm registry. The latest
Analysis Summary
# Incident Report: Rspack NPM Package Supply Chain Compromise
## Executive Summary
Two popular Rspack npm packages, `@rspack/core` and `@rspack/cli`, were compromised in a software supply chain attack, resulting in the publication of malicious versions containing cryptocurrency mining malware. The attack leveraged unauthorized publishing access to inject payloads that executed upon installation via postinstall scripts. The response involved quickly unpublishing the malicious versions and releasing clean updates to mitigate further infections.
## Incident Details
- **Discovery Date:** December 20, 2024 (Based on publication date of the report)
- **Incident Date:** Sometime prior to December 20, 2024 (When malicious versions were published)
- **Affected Organization:** Rspack Project (Developed initially by ByteDance, used by Alibaba, Amazon, Discord, Microsoft)
- **Sector:** Software Development / Open Source Ecosystem
- **Geography:** Global (Affected users globally via npm registry)
## Timeline of Events
### Initial Access
- **Date/Time:** Not explicitly stated, but occurred before the discovery on Dec 20, 2024.
- **Vector:** Compromise of the attacker's ability to publish to the official npm registry (Unauthorized npm publishing access).
- **Details:** An attacker gained publishing rights to the Rspack official packages.
### Lateral Movement
- Not applicable as this was a supply chain injection rather than an internal network breach. The malware spread via distribution through the npm registry.
### Data Exfiltration/Impact
- **What was stolen or damaged:** Malicious scripts attempted to exfiltrate sensitive configuration details, including cloud service credentials, by communicating with a remote server (`http://80.78.28[.]72`). The primary impact was the installation of an XMRig cryptocurrency miner on compromised Linux hosts.
### Detection & Response
- **How it was discovered:** The malicious versions were discovered and analyzed by the Rspack developers and security firm Socket.
- **Response actions taken:** Versions 1.1.7 of both `@rspack/core` and `@rspack/cli` were immediately unpublished from the npm registry.
## Attack Methodology
- **Initial Access:** Unauthorized publishing ability to the npm registry for two specific packages.
- **Persistence:** The malware was executed via a `postinstall` script specified in the `package.json` file, ensuring execution immediately upon package installation.
- **Privilege Escalation:** Not explicitly detailed, but payload execution implies system permissions necessary to run the XMRig miner on Linux hosts.
- **Defense Evasion:** The malware included **geofencing**, limiting the infection to machines only located in specific countries (China, Russia, Hong Kong, Belarus, and Iran).
- **Credential Access:** Attempted to transmit sensitive configuration details, including cloud service credentials, to a remote adversary-controlled server.
- **Discovery:** Executed an HTTP GET request to `ipinfo[.]io/json` to collect IP address and location details for geofencing.
- **Lateral Movement:** Not the primary mechanism; the threat propagated via the package registry itself.
- **Collection:** Cloud service credentials and system location/IP information.
- **Exfiltration:** Data was sent to the remote server `http://80.78.28[.]72`.
- **Impact:** Deployment and execution of an XMRig cryptocurrency miner.
## Impact Assessment
- **Financial:** Not quantified, but included the cost of cryptocurrency mining and potential cloud credential compromise.
- **Data Breach:** Sensitive configuration details, including cloud service credentials, were targeted for exfiltration.
- **Operational:** Disruption occurred for users installing the malicious versions, primarily leading to unauthorized resource consumption (CPU cycles) due to crypto mining.
- **Reputational:** Damage to the trust placed in the Rspack open-source project and the npm ecosystem generally.
## Indicators of Compromise
- **Network indicators (Defanged):**
- Exfiltration/C2 Server: `80.78.28[.]72`
- Location Check Endpoint: `ipinfo[.]io`
- **File indicators:** Malicious code embedded within Rspack npm packages, executing via `postinstall` script. Likely included the XMRig miner payload.
- **Behavioral indicators:**
- Installation of packages triggering execution of a `postinstall` script without user intervention.
- Outbound network connections to the listed C2 server upon installation.
- System activity consistent with cryptocurrency mining (high CPU usage).
## Response Actions
- **Containment measures:** Versions 1.1.7 of `@rspack/core` and `@rspack/cli` were immediately unpublished from the npm registry.
- **Eradication steps:** The project maintainers published new, clean versions (1.1.8) excluding the malicious code.
- **Recovery actions:** Users were instructed to update to the safe version (1.1.8) to remove the threat.
## Lessons Learned
- **Key takeaways:** Supply chain attacks remain a critical threat vector, even for widely used tools like Rspack. Automated execution via `postinstall` scripts provides attackers with an easy, hands-off method for initial payload delivery.
- **What could have been done better:** The incident highlights the need for enhanced repository authentication/access controls to prevent unauthorized publishing.
## Recommendations
- **Prevention measures for similar incidents:**
1. Implement multi-factor authentication (MFA) for all publishing accounts associated with critical packages.
2. Review and restrict publishing rights to only essential maintainers.
3. Utilize automated dependency scanning tools to monitor package contents for anomalous execution post-install hooks.
4. For high-risk dependencies, consider pinning versions and implementing integrity checking or signing mechanisms (if supported by the deployment pipeline).