TLDR
- Malicious versions of the xrpl SDK on NPM leaked private keys. Update to v4.2.5 immediately.
- Fake SDKs (v4.2.1–v4.2.4, v2.14.2) were uploaded with a backdoor. Private keys may be compromised.
- The XRP Ledger core is safe. Only the NPM JavaScript SDK was affected by the breach.
- Developers should update, rotate keys, and use lockfiles to prevent future supply chain attacks.
- A hacker snuck harmful code into the XRP SDK. New safe version released—upgrade now.
A significant security vulnerability has been identified in the XRP Ledger’s JavaScript Software Development Kit (SDK), specifically within several recently published versions of the xrpl package on the Node Package Manager (NPM). The breach, disclosed by Aikido Security on, has prompted an immediate response from the XRP Ledger Foundation and developers across the XRP ecosystem.
The malicious code, described as a backdoor, was embedded in versions v4.2.1 through v4.2.4 and v2.14.2 of the SDK. These versions were uploaded to NPM by a user identified as “mukulljangid” and did not match any legitimate releases from the official GitHub repository. The vulnerability could enable attackers to extract private keys from users and developers utilizing the affected SDK versions, posing a serious threat to wallet security and user funds.
Supply Chain Attack Identified in xrpl.js
Aikido Security’s automated monitoring system detected the issue shortly after the compromised packages were published. The firm noted that these SDK versions were distributed through NPM and were inconsistent with the XRP Ledger’s official release history on GitHub, raising immediate concerns about a supply chain compromise.
The vulnerability was discovered within a function called checkValidityOfSeed, which was covertly integrated into the wallet instantiation logic. This function triggered a remote call to an unverified domain—0x9c[.]xyz—during wallet creation, silently transmitting private key information. According to Aikido Security, early compromised versions (v4.2.1 and v4.2.2) contained the malicious code in built JavaScript files. Later versions (v4.2.3 and v4.2.4) embedded the backdoor deeper into the TypeScript source files.
In addition to the backdoor, the compromised packages showed signs of deliberate tampering, including the removal of development tools and scripts from the package.json file. These modifications are consistent with attempts to obfuscate unauthorized changes and reduce detection during audits or development.
Ecosystem Response and Mitigation Measures
The XRP Ledger Foundation responded quickly to the disclosure, confirming the vulnerability via social media on April 22. The foundation clarified that the core XRP Ledger codebase and its GitHub repository were not affected. Instead, the issue was isolated to the xrpl.js JavaScript SDK distributed through NPM.
Earlier today, a security researcher from @AikidoSecurity identified a serious vulnerability in the xrpl npm package (v4.2.1-4.2.4 and v2.14.2).
We are aware of the issue and are actively working on a fix.
A detailed post-mortem will follow.
— XRP Ledger Foundation (Official) (@XRPLF) April 22, 2025
Engineers have since published a new version, v4.2.5, which replaces the affected versions and eliminates the backdoor. Developers and projects that relied on versions v4.2.1 through v4.2.4 and v2.14.2 have been strongly advised to upgrade immediately . As a precaution, users are encouraged to transfer assets to new wallets generated with uncompromised software.
Several projects using the XRP Ledger SDK, including Xaman Wallet and XRPScan, confirmed they were not impacted, having not integrated the affected versions. Meanwhile, Gen3 Games CTO Mark Ibanez stated that his team narrowly avoided exposure by maintaining a version lock in their pnpm-lock.yaml file.
Ibanez recommended standard security practices such as committing lockfiles to version control and avoiding the caret symbol (^) in package.json dependencies. These measures, while routine, proved effective in shielding some projects from the compromised SDK.
