Full Report
The Ripple cryptocurrency npm JavaScript library named xrpl.js has been compromised by unknown threat actors as part of a software supply chain attack designed to harvest and exfiltrate users' private keys. The malicious activity has been found to affect five different versions of the package: 4.2.1, 4.2.2, 4.2.3, 4.2.4, and 2.14.2. The issue has been addressed in versions 4.2.5 and 2.14.3.
Analysis Summary
# Incident Report: Supply Chain Attack on Ripple's xrpl.js npm Package
## Executive Summary
A significant supply chain attack compromised the Ripple cryptocurrency npm JavaScript library, `xrpl.js`, through a backdoored package update. Threat actors gained access, likely via a stolen npm access token belonging to a Ripple account, to introduce malicious code designed to steal users' private keys. The immediate response involved releasing patched versions, advising users to update immediately to mitigate further compromise of cryptocurrency wallets.
## Incident Details
- Discovery Date: April 23, 2025 (Implied, based on article publication date)
- Incident Date: Starting April 21, 2025
- Affected Organization: Ripple (Affecting the `xrpl.js` library users)
- Sector: Blockchain / Cryptocurrency
- Geography: Not explicitly stated, but impacts global users of the npm package.
## Timeline of Events
### Initial Access
- **Date/Time:** Starting April 21, 2025
- **Vector:** Compromised npm account credentials (likely an access token) belonging to a user named "mukulljangid" (believed to be a Ripple employee).
- **Details:** Attackers managed to upload backdoored versions of the library to the npm registry.
### Lateral Movement
- N/A (This was a direct code injection/supply chain attack targeting an endpoint library, not traditional internal network movement.)
### Data Exfiltration/Impact
- **What was stolen or damaged:** Cryptocurrency private keys were harvested from users implementing the compromised library versions. The malicious code introduced a function (`checkValidityOfSeed`) engineered to transmit stolen data to an external domain (`0x9c[.]xyz`).
### Detection & Response
- **How it was discovered:** Public disclosure/security tooling identified the malicious updates on or around April 23, 2025.
- **Response actions taken:** New, clean versions (4.2.5 and 2.14.3) were immediately released to address the vulnerable versions (4.2.1, 4.2.2, 4.2.3, 4.2.4, and 2.14.2).
## Attack Methodology
- **Initial Access:** Account takeover of the publishing npm account (`mukulljangid`), achieved by stealing the access token.
- **Persistence:** Not applicable in the traditional sense, but persistence was achieved by delivering the malicious code via newly published, seemingly legitimate package versions.
- **Privilege Escalation:** N/A (Attackers gained publishing authority through credential compromise).
- **Defense Evasion:** Attackers tried different ways to sneak in the backdoor across subsequent versions released in a short span of time to evade detection.
- **Credential Access:** The payload was specifically designed to access and exfiltrate user private keys/seed phrases.
- **Discovery:** N/A (External researchers/security tools identified the malicious uploads).
- **Lateral Movement:** N/A
- **Collection:** The malicious function `checkValidityOfSeed` collected private key data.
- **Exfiltration:** Stolen data was transmitted to a hardcoded external domain (`0x9c[.]xyz`).
- **Impact:** Theft of cryptocurrency private keys, leading to potential loss of user funds.
## Impact Assessment
- **Financial:** Potential loss of user cryptocurrency funds (specific estimate not provided).
- **Data Breach:** Confidential security credentials (private keys/seed phrases) belonging to users of the library were compromised.
- **Operational:** Disruption to developers relying on the library, requiring mandatory updates. The XRP Ledger codebase and GitHub repository were *not* affected.
- **Reputational:** Damage to trust in the Ripple ecosystem's software distribution security.
## Indicators of Compromise
- **Network indicators (Defanged):** `0x9c[.]xyz`
- **File indicators:** Backdoored functionality introduced via a function named `checkValidityOfSeed`.
- **Behavioral indicators:** Stolen private key information being transmitted out of client applications using the vulnerable package versions.
## Response Actions
- **Containment measures:** Immediate urging of all users to stop using versions 4.2.1 through 4.2.4 and 2.14.2.
- **Eradication steps:** Release of patched package versions (4.2.5 and 2.14.3) containing no malicious code.
- **Recovery actions:** Users needed to upgrade their dependencies to the trusted versions immediately.
## Lessons Learned
- Publishing account security, even for trusted maintainers, is a critical vector in supply chain attacks (e.g., compromised npm access tokens).
- Multiple versions were released quickly, indicating an active attempt by the attacker to maintain persistence or bypass initial basic security checks.
- The core source repository (GitHub) remained clean, highlighting a distinction between the registry publishing mechanism security and repository security.
## Recommendations
- Implement stronger multi-factor authentication (MFA) and granular access controls for all accounts with publishing rights to critical software registries (like npm).
- Conduct regular audits of active sessions and tokens associated with publishing accounts.
- Developers using third-party packages should maintain rigorous dependency management, pinning versions where possible, and monitoring for sudden, suspicious update bursts from maintainers.