A critical supply chain attack on the xrpl.js JavaScript library—the recommended package for interacting with the XRP Ledger—has exposed the private keys of cryptocurrency developers and users who downloaded compromised versions on April 21, 2025. The breach, tracked as CVE-2025-32965 with a CVSS severity score of 9.3, represents one of the most significant software supply chain incidents to hit the cryptocurrency ecosystem this year.
The Exploit Mechanics
The attack targeted the official xrpl.js npm package maintained by the XRP Ledger Foundation. A threat actor compromised the npm account of a Ripple developer known as “mukulljangid” and injected a malicious function called checkValidityOfSeed into five versions of the library: 4.2.1, 4.2.2, 4.2.3, 4.2.4, and 2.14.2.
The compromised versions were published to the npm registry on April 21, 2025, between 4:46 PM and 5:49 PM Eastern Time. The malicious code operated by intercepting sensitive wallet data—seed phrases, private keys, and mnemonic phrases—whenever these values were processed through the library’s standard wallet functions. The stolen data was then transmitted via HTTP POST requests to an attacker-controlled domain at 0x9c.xyz.
To evade detection, the threat actor disguised the exfiltration traffic by using an “ad-refferal” user agent string, making the data transfers appear as routine advertising requests to network monitoring systems. The attacker iterated through multiple versions in rapid succession, suggesting attempts to refine the backdoor and avoid discovery by security researchers.
Affected Systems
The xrpl.js library has been downloaded over 2.9 million times to date and attracts more than 135,000 weekly downloads, making it a high-value target for supply chain attacks. The five compromised versions accumulated a total of 452 downloads before being removed from the npm registry. While this number may appear modest, each download potentially represents a development environment or application managing a far larger number of XRP wallets.
Projects confirmed as unaffected include Xaman Wallet, XRPScan, First Ledger, and Gen3 Games. Critically, the XRP Ledger codebase itself and the associated GitHub repository were not impacted—the attack was limited to the npm publishing pipeline, indicating the attacker gained access to the developer’s npm credentials rather than the source code repository.
The XRP Ledger Foundation issued an urgent advisory stating: “This vulnerability is in xrpl.js, a JavaScript library for interacting with the XRP Ledger. It does not affect the XRP Ledger codebase or GitHub repository itself. Projects using xrpl.js should upgrade to v4.2.5 immediately.”
The Mitigation Strategy
The XRP Ledger Foundation released clean versions 4.2.5 and 2.14.3 to address the vulnerability. The compromised versions have been removed from the npm registry. However, remediation extends beyond simply updating the package version.
Organizations and developers who used any of the compromised versions must immediately rotate all private keys and secrets that were processed through the library. The XRP Ledger supports key rotation, and affected users should assign new regular key pairs to their accounts. Any account whose master key may have been compromised should have its master key disabled entirely.
Security firm Aikido, which first identified the backdoor alongside researchers Charlie Eriksen, emphasized that developers should not assume limited downloads mean limited impact. A single compromised build pipeline could expose thousands of end-user wallets if the library was used in production applications.
Lessons Learned
This incident underscores the persistent threat of supply chain attacks in the cryptocurrency ecosystem. The attack vector—compromising a legitimate developer’s publishing credentials rather than introducing malicious code through the public repository—is particularly dangerous because it bypasses code review processes entirely.
The speed of the attack is also noteworthy. Five malicious versions were published within just over one hour, suggesting a well-prepared and automated attack infrastructure. Organizations that rely on npm packages for cryptocurrency operations should implement lockfiles, verify package integrity checksums, and consider using private package registries with automated security scanning.
The incident also highlights the importance of npm access token hygiene. Developers should use short-lived tokens, enable two-factor authentication on their npm accounts, and monitor for unauthorized publishing activity.
User Action Required
If you have used xrpl.js versions 4.2.1 through 4.2.4 or version 2.14.2 in any project, take the following steps immediately:
1. Upgrade to version 4.2.5 or 2.14.3 without delay.
2. Rotate all private keys and wallet seeds that were processed through the compromised library.
3. Transfer funds from potentially exposed wallets to new, secure wallets.
4. Disable compromised master keys using the XRP Ledger’s key rotation feature.
5. Audit your application logs for any outbound connections to the 0x9c.xyz domain.
Disclaimer: This article is for informational purposes only and does not constitute financial or security advice. Always consult with qualified security professionals regarding cryptocurrency wallet security.
Most altcoins will go to zero but the winners will 100x
Layer 1 competition is heating up but ETH still dominates
L1 token valuations need to be judged by developer activity
developer activity literally got them exploited here. the more active the dev ecosystem the bigger the supply chain attack surface becomes
9.3 severity and the attacker just needed one compromised npm account. software supply chain security is the weakest link in crypto by far
one npm account. no 2FA. for a library handling private keys worth millions. the systemic risk in npm is still not fixed
one npm account compromised and the entire xrpl.js ecosystem was at risk. this is why npm needs mandatory 2FA for all packages over 10k downloads
npm_audit_ mandatory 2FA is table stakes. npm should also require hardware key attestation for packages with over 100k weekly downloads
the malicious function was literally called checkValidityOfSeed. you cannot make this up. hiding key theft behind a function name that sounds like a security check
naming it checkValidityOfSeed while stealing seeds is genuinely psychopathic humor. the attacker understood developer psychology perfectly
Sakura checkValidityOfSeed is diabolical naming. the attacker literally named the key theft function something that sounds like a security feature