A sophisticated supply chain attack targeting the widely-used Ripple xrpl.js npm library has sent shockwaves through the cryptocurrency development community, exposing the private keys of potentially thousands of developers and users. The incident, assigned CVE-2025-32965 with a critical CVSS score of 9.3, underscores the persistent vulnerabilities lurking in open-source software dependencies that underpin the blockchain ecosystem.
The Exploit Mechanics
The attack vector was deceptively simple yet devastatingly effective. Unknown threat actors compromised the npm account of a Ripple developer operating under the username “mukulljangid” and injected malicious code into five consecutive versions of the xrpl.js package: 4.2.1, 4.2.2, 4.2.3, 4.2.4, and 2.14.2. The malicious payload introduced a new function called checkValidityOfSeed, which was engineered to quietly exfiltrate cryptocurrency private keys to an external command-and-control server hosted at the domain 0x9c[.]xyz.
What makes this attack particularly insidious is the iterative approach the attackers took. Rather than pushing a single compromised version, they refined their backdoor across multiple releases, testing different techniques to evade detection. Each subsequent version featured slight modifications to the malicious code, suggesting the threat actors were actively monitoring for discovery and adapting their approach accordingly. The GitHub repository itself was not compromised — only the npm distribution channel was affected.
The xrpl.js library serves as the primary JavaScript API for interacting with the XRP Ledger blockchain, originally developed by Ripple Labs in 2012. With over 2.9 million total downloads and approximately 135,000 weekly downloads, the potential blast radius of this attack is enormous. Any developer who integrated one of the compromised versions into their application could have inadvertently exposed the private keys of their users.
Affected Systems
The impact extends far beyond individual developers. Any cryptocurrency wallet, exchange integration, payment processor, or decentralized application that relied on the compromised versions of xrpl.js for XRP Ledger interactions is potentially affected. This includes automated trading bots, cross-border payment solutions, and institutional custody platforms that use JavaScript-based XRP integrations.
The attack surface is amplified by the nature of supply chain compromises: developers who installed the compromised packages may not realize their private keys were exfiltrated until funds are moved. Given that the malicious versions were available for several days before detection, there is a significant window during which attackers could have harvested credentials and prepared targeted wallet drains.
Bitcoin was trading at approximately $76,352 and Ethereum at $2,327 at the time of the incident, meaning even a single compromised high-value wallet could result in losses amounting to hundreds of thousands of dollars. The full extent of financial losses remains under investigation.
The Mitigation Strategy
The XRP Ledger Foundation acted swiftly once the compromise was identified, releasing patched versions 4.2.5 and 2.14.3 that remove the malicious code. In an official advisory, the Foundation stated: “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.”
Aikido Security, whose researcher Charlie Eriksen first documented the attack, has provided a comprehensive set of mitigation steps. All users running affected versions must immediately stop using them, upgrade to the patched releases, and — critically — rotate any private keys or secrets that were used with the compromised systems. Simply updating the package is insufficient if keys have already been exposed.
For organizations with significant XRP holdings, the recommended approach is to transfer funds to entirely new wallets generated on clean, uncompromised systems. Hardware security modules and cold storage solutions should be used for any high-value operations going forward.
Lessons Learned
This incident reinforces several critical lessons for the cryptocurrency industry. First, supply chain security is only as strong as the weakest link in the development pipeline. A single compromised developer credential — whether obtained through phishing, credential stuffing, or insider access — can undermine the trustworthiness of an entire software ecosystem. The fact that the attacker gained access to a legitimate Ripple employee npm account highlights the need for multi-factor authentication and short-lived access tokens on all package distribution platforms.
Second, the attack demonstrates the importance of runtime monitoring and integrity verification for critical dependencies. Organizations that had implemented automated checksum verification or runtime integrity checks would have been able to detect the unauthorized code changes much earlier. Lock files and pinned dependencies, while not foolproof, also provide an additional layer of protection against automatic propagation of compromised updates.
Third, the cryptocurrency industry must invest more heavily in proactive security auditing of critical infrastructure libraries. With 135,000 weekly downloads, xrpl.js is clearly a high-value target that warrants dedicated security review and formal verification processes.
User Action Required
If you have used any version of xrpl.js between 4.2.1 and 4.2.4, or version 2.14.2, take the following steps immediately: update to version 4.2.5 or 2.14.3, rotate all private keys that were used with the affected library, move any exposed funds to new secure wallets, and audit your transaction history for unauthorized transfers. Developers should also review the GitHub security advisory GHSA-33qr-m49q-rxfx for the complete technical details and implement the recommended mitigations across their entire dependency chain.
Disclaimer: This article is for informational purposes only and does not constitute financial or security advice. Always consult with qualified security professionals for incident response.
The market is finally rewarding fundamentals over hype
The rotation from memes to utility tokens has started
Layer 1 competition is heating up but ETH still dominates
This altseason rotation is different — actual utility is driving gains
5 consecutive versions with malicious code. they were iterating on the backdoor across releases which means they were actively monitoring for detection
npm_paranoia iterating across 5 versions means they had a QA process for their backdoor. state-level effort going after private keys
state-level is right. 5 versions with QA on a backdoor, domain registered days before. this isnt some random hacker, its a funded operation
5 versions of QA on a backdoor with a fresh domain registration. this is a team with resources, not a lone researcher. APT level coordination
2.9M total downloads and the github repo wasnt even compromised. npm is the weak link not the source code
2.9M downloads from a github repo that was fine. the npm registry IS the supply chain. nobody reinstalls from source after the first npm install
jessica exactly. npm is the de facto supply chain for all of javascript and theres no artifact signing requirement. the xz utils backdoor in linux was the same pattern
Akira the npm registry being the weak link is a systemic problem. 2.9M downloads and no one verified the package against the github source