Full Report
The recommended Ripple cryptocurrency NPM JavaScript library named "xrpl.js" was compromised to steal XRP wallet seeds and private keys and transfer them to an attacker-controlled server, allowing threat actors to steal all the funds stored in the wallets. [...]
Analysis Summary
# Incident Report: XRP Library (xrpl.js) Compromise and Wallet Seed Theft
## Executive Summary
A supply chain attack targeted the recommended Ripple XRP JavaScript library, `xrpl.js`, through its NPM package distribution. Attackers injected malicious code into several versions of the library, specifically exploiting the `checkValidityOfSeed()` function to steal users' XRP wallet seeds, private keys, and mnemonics. The resulting impact is a high risk of fund theft for any user who installed the compromised versions, prompting immediate advice to rotate keys.
## Incident Details
- Discovery Date: Not explicitly stated, but implied shortly after malicious package upload (April 21, 2025).
- Incident Date: Monday, April 21, 2025 (Multiple versions uploaded within a few hours).
- Affected Organization: Ripple (via compromise of their recommended library, xrpl.js).
- Sector: Cryptocurrency / Blockchain (XRP Ledger).
- Geography: Global (NPM package distribution).
## Timeline of Events
### Initial Access
- Date/Time: Monday, April 21, 2025 (Multiple times between 4:46 PM ET and 5:49 PM ET).
- Vector: Supply Chain Compromise (Malicious code injection into the NPM package publishing pipeline).
- Details: Compromised credentials for a developer account associated with the Ripple organization were likely used to publish malicious versions of `xrpl.js`. The malicious commits were not visible in the public GitHub repository, suggesting the compromise occurred during the NPM publishing step.
### Lateral Movement
- Not Applicable / Not detailed in this context. The attack was focused on package integrity rather than network lateral movement within an organization's infrastructure.
### Data Exfiltration/Impact
- Infected versions were downloaded 452 times (cumulative).
- The malicious code in the `checkValidityOfSeed()` function was designed to steal users' **XRP wallet seeds, private keys, and mnemonics**.
- Attackers can use this stolen information to import wallets onto their own devices and drain funds.
### Detection & Response
- Detection: Implied discovery based on public reporting shortly after the malicious versions were published.
- Response actions taken: Public advisories were issued urging users to immediately stop using the compromised versions, rotate any private keys or secrets, and provided links on how to disable master key pairs or assign regular key pairs for enhanced security.
## Attack Methodology
- Initial Access: Supply Chain compromise via NPM publishing pipeline.
- Persistence: Not applicable (Functionality embedded in the published software package).
- Privilege Escalation: Not applicable to the attacker's method against the library maintainer's account.
- Defense Evasion: Malicious code was hidden from the public GitHub repository, only appearing in the published NPM package.
- Credential Access: N/A (Attackers harvested user *wallet* credentials/seeds, not system credentials).
- Discovery: N/A (Direct attack on functionality).
- Lateral Movement: N/A.
- Collection: Stealing private keys, seeds, and mnemonics via the modified `checkValidityOfSeed()` function.
- Exfiltration: Implied exfiltration of harvested wallet data (method not detailed).
- Impact: Fund theft from compromised XRP wallets.
## Impact Assessment
- Financial: Potential for significant financial loss due to unauthorized draining of user XRP wallets.
- Data Breach: Exposure and theft of sensitive cryptographic material (XRP seeds, private keys, mnemonics).
- Operational: Disruption for developers using the compromised library, requiring immediate remediation (key rotation).
- Reputational: Negative impact on trust in libraries distributed for the XRP Ledger ecosystem.
## Indicators of Compromise
- Network indicators: Not provided in defanged format.
- File indicators: Compromised versions include: `4.2.1, 4.2.2, 4.2.3, 2.14.2, 4.2.4`.
- Behavioral indicators: Execution of the malicious logic within the **`checkValidityOfSeed()` function** of the `xrpl.js` library upon usage.
## Response Actions
- Containment measures: Immediately ceasing use of the compromised library versions.
- Eradication steps: Developers must stop using the listed versions.
- Recovery actions: Users advised to rotate all potentially compromised private keys/secrets and disable master key pairs using XRP Ledger tools if necessary.
## Lessons Learned
- Key takeaway: Dependency trust is a critical vulnerability point; malicious code can be injected directly into the distribution pipeline (NPM) without showing in source control (GitHub).
- What could have been done better: Stronger multi-factor authentication or stricter publishing controls on developer accounts associated with critical infrastructure software. Monitoring package integrity post-publication is vital.
## Recommendations
- Implement strict access controls and MFA for all accounts capable of publishing packages to major repositories (NPM, PyPI, etc.).
- Utilize dependency scanning tools that can check published artifacts against source code repositories, particularly for critical security functions.
- Developers must prioritize key rotation immediately if any dependency update coincided with unexpected wallet activity.
- For critical wallets, reliance on proprietary, recommended libraries should be offset by stringent security auditing or consideration of alternative, more widely vetted implementations.