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.
5 compromised versions in one hour. that attacker knew exactly which packages to target and when. this was coordinated not opportunistic
checkValidityOfSeed stealing seeds while sounding like a security feature. social engineering at the code level
CVE 9.3 on a wallet library and people still npm install without lockfile verification in 2025. unsigned packages are the soft underbelly of the entire ecosystem
checkValidityOfSeed is genuinely evil naming. hides the exfiltration in a function that sounds like it protects you. whoever wrote that knew exactly what they were doing
Pavel J. the 5 compromised versions in about an hour window means the attacker had the payload pre-built. this was not opportunistic, someone planned the injection path well in advance
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
one npm account with no 2FA controlling a library that handles XRP private keys. npm still doesnt mandate 2FA for packages above 100k weekly downloads. criminal negligence
npm_hardliner_ npm not mandating 2FA for packages over 100k downloads in 2025 is genuinely negligent. the ecosystem learned nothing from event-stream in 2018
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
exfil_tracer_ npm had years to mandate 2FA and chose not to. this was inevitable. the real question is how many other wallet libraries got quietly compromised and nobody noticed yet
exfil_tracer_ npm still doesnt require 2FA for packages above 100k downloads. one account with weak credentials can poison the entire import chain
sig_store_rat_ npm not requiring hardware key attestation for packages handling private keys is the real CVE here. the xrp ledger foundation should have demanded better opsec from their own maintainers
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
5 versions pushed in about an hour on a package handling private keys. npm should have rate-limited that automatically but they still dont have basic fraud detection for high-risk packages
package_lock_skep npm still doesnt rate-limit version publishes on critical packages. a maintainer account gets phished and 5 malicious versions go live before anyone can react. the platform learned nothing
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
the HTTP POST exfiltration went to a server that was active for over an hour before anyone noticed. npm package signing was proposed in 2021 and still isnt mandatory. incredible
CVE score 9.3 for a compromise that took exactly one phishing email to execute. the technical sophistication was zero, the impact was catastrophic