The xrpl.js Supply Chain Attack

What happened

An attacker phished a Ripple employee who helps maintain the package. The attacker then used the npm account to publish five malicious versions. The XRP Ledger disclosure report gives this timeline in UTC:

• 21 April 2025, 20:39: the employee's credentials are phished.
• 21 April 2025, 20:46 to 21:49: five malicious versions are published.
• 22 April 2025, 08:14: a security researcher alerts Ripple.
• 22 April 2025, 08:14 to 12:34: Ripple completes its mitigation.

The injected code targeted two functions: generate and fromRFC1751Mnemonic. A function called checkValidityOfSeed sent the secret key material to the attacker. When a user created a key or imported a mnemonic, the library silently copied the secret.

The Hacker News names the receiving domain as 0x9c.xyz. Before the attack the top-level index file only re-exported other modules and contained no HTTP code.

Ripple removed the compromised maintainer access, turned on two-factor authentication for all npm users of the package, deprecated the bad versions and reported the attacker domain to registrars.

Affected versions

• Malicious: xrpl 4.2.1, 4.2.2, 4.2.3, 4.2.4 (GitHub advisory range: 4.2.1 up to but not including 4.2.5).
• Malicious: xrpl 2.14.2. The advisory says it carries less risk because it is not compatible with the other 2.x releases.
• Patched: 4.2.5 and 2.14.3.
• Last clean releases before the attack: 4.2.0 and 2.14.1.

The advisory GHSA-33qr-m49q-rxfx tracks this as CVE-2025-32965 with a CVSS score of 9.3 (Critical).

Indicators of compromise

• Domain: 0x9c.xyz (outbound HTTP requests from your app during key generation).
• Function name in the package code: checkValidityOfSeed.
• Installed xrpl version 4.2.1 to 4.2.4 or 2.14.2.
• Compromised publisher account named in press reports: npm user mukulljangid.

How to check

Check which xrpl version each project resolves. This includes versions that other packages pull in.

npm ls xrpl

Search your installed copies and lockfiles for the function name and the domain.

grep -rl "0x9c.xyz" node_modules/xrpl; grep -n "xrpl" package-lock.json | head

Check build and deploy logs from 21 April 2025 onward for installs of an affected version.

What to do now

1. Upgrade xrpl to 4.2.5 or 2.14.3 or later.
2. If an affected version ran with real keys, assume those wallets are compromised.
3. Rotate every private key and secret that you generated or imported with an affected version.
4. Use the XRP Ledger key rotation features to disable master keys that are at risk.
5. Move funds to new, secure wallets.
6. Rebuild from a clean lockfile and block the domain on your network.

Vigilance compares the version you trust with a new one. Here, the index file gained a function that sends seed material over HTTP. The file had no network code in 4.2.0. That is the change Vigilance reports.

What Vigilance showed

Vigilance compares the version you trust with the new one and names the file that gained a new capability. The block below is rebuilt from the public reports in the words Vigilance prints. It is not a captured scan, because the malicious release is not redistributed.

files scanned: 37

HEADS UP  1 file can now do things the old version could not. The rest changed and gained nothing.

CHANGED    package.json
           It now reads saved passwords and access keys. It did not before.

Sources

1. github.com/advisories/GHSA-33qr-m49q-rxfx
2. xrpl.org/blog/2025/vulnerabilitydisclosurereport-bug-apr2025
3. thehackernews.com/2025/04/ripples-xrpljs-npm-package-backdoored.html