The xrpl.js Backdoor Explained

Video transcript

A phished npm login let an attacker ship five backdoored versions of the XRP Ledger SDK, xrpl dot js, that leaked wallet seeds and keys.

A Ripple employee who helps maintain the package was phished. The attacker published straight to npm, bypassing all pull request approvals. The XRP Ledger itself was unaffected.

Five versions went out in just over an hour. GitHub's advisory rates it Critical, with a CVSS score of 9.3.

A function named check validity of seed actually sent secrets to the attacker. Calls sat in the Wallet constructor, seed and entropy creation, mnemonic loading and derive wallet.

The first bad version went live seven minutes after the phish, and Aikido's feed alerted soon after. An Aikido researcher told Ripple the next morning.

Exposure needed a bad version plus code that created or loaded a wallet. No theft is confirmed, but affected users should assume compromise and move funds.

The npm versions matched no GitHub release. Review guarded the repo, but publishing needed only stolen credentials. Check every published version against a tagged, reviewed release.

Guardian's SDK Audit reviews the source and the published package, because the gap between them is where supply chain risk lives. It checks what ships, who can publish, and key handling.

Read the full article, or talk to Guardian about an SDK Audit at guardian.security.

Aikido calls xrpl.js "the official SDK for the XRP Ledger," with more than 140,000 weekly downloads.

On April 21, 2025, five releases of it on npm carried a backdoor that sent wallet secrets to an attacker.

The XRP Ledger itself was not affected, the disclosure report says. The malicious code lived only in the npm package.

What Happened

The disclosure report on xrpl.org gives the cause. At 20:39 UTC on April 21, "a Ripple employee who helps maintain the affected package was phished for their credentials."

The attacker used that account to publish straight to npm, "bypassing all PR approval processes," the report says.

No GitHub repositories were compromised at any time, it adds. The phishing "specifically targeted npm."

Five malicious versions went out in just over an hour: 4.2.1, 4.2.2, 4.2.3, 2.14.2 and 4.2.4.

GitHub's advisory, GHSA-33qr-m49q-rxfx, rates the issue Critical. It is CVE-2025-32965, with a CVSS 4.0 score of 9.3.

How the Backdoor Worked

The attacker added a function named checkValidityOfSeed. Despite the name, it sent what it received to 0x9c[.]xyz, a domain Aikido described as brand new.

The value traveled in an HTTP header named ad-referral, Aikido's code excerpt shows.

Calls to it sat in the code that creates or loads a wallet:

• The Wallet constructor
• fromSeed, fromEntropy and generate
• fromMnemonic and fromRFC1751Mnemonic
• deriveWallet

Creating any Wallet object sent its private key, Aikido found. The other paths also sent seeds and mnemonics.

The attacker iterated

The method changed between releases, according to Aikido:

• 4.2.1 and 4.2.2: code inserted into the built JavaScript files.
• 4.2.3 and 4.2.4: the backdoor added to the TypeScript source and compiled in.

Aikido read this as an attacker "trying different ways to insert the backdoor while remaining as hidden as possible."

From 4.2.1 on, the scripts and prettier configuration were also removed from package.json.

Timeline and Impact

Times are UTC, from the disclosure report unless noted.

Exposure took two things: an affected version installed, and code that created or loaded a wallet with it.

Aikido's window for installs runs from 20:53 UTC on April 21 to 13:00 UTC on April 22.

GitHub's advisory says 2.14.2 is "less likely to lead to exploitation," as it is not compatible with other 2.x versions.

No theft is confirmed in the sources we read. The report said: "As of today, no downstream effects have been reported."

It still told anyone who installed the bad versions to "assume their wallets are compromised."

What It Shows

The registry and the repo disagreed. Aikido noted the versions did not match the releases on GitHub, where the latest was 4.2.0.

That gap is checkable: compare each published version with a tagged, reviewed release.

Review stopped at GitHub. Pull request approvals guarded the repository, but publishing to npm needed only the stolen credentials.

Detection came from outside. Aikido's feed began alerting at 20:53 UTC. A researcher from Aikido Security alerted Ripple at 08:14 the next morning, the report says.

Every key path is a hiding place. The backdoor sat in each function that creates or loads a wallet, under a name that sounds like validation.

The fixes target release control. Ripple and the XRPL Foundation say they have "enabled 2FA for all users in npmjs.com" and removed the compromised maintainer.

They also plan automated release verification, monitoring for anomalies in publishing and a review of who can publish.

The same pattern hit Solana a few months earlier: see the @solana/web3.js backdoor. Our npm supply chain guide covers lockfiles, cooldowns and install controls.

How SDK Audit Tests This

Guardian's SDK Audit reviews what a library does with a payload and "what one bad release would do," its service page says.

Three of its six areas match this incident:

• Published artifact: what ships to the registry versus the repo, including install scripts and dependencies.
• Release control: who can publish, whether 2FA and provenance are enforced, how a bad version gets pulled.
• Key and credential handling: signers, seeds, tokens and API keys, how long they stay in memory, what leaks to logs.

Guardian reviews both the source and the published package. Its page says "the gap between them is where supply-chain risk lives."

The audit covers TypeScript, Python, Rust, Go and JVM client libraries for EVM and Solana. It is scoped by the public surface and the release pipeline.

After release, Managed Security matches new vulnerability disclosures against what you run. Where one reaches you, an engineer confirms the exposure and works with you on the patch.

For the wider offchain scope, read web3 penetration testing explained.

Frequently Asked Questions

Which xrpl.js versions were malicious?

Versions 4.2.1, 4.2.2, 4.2.3, 4.2.4 and 2.14.2 of the xrpl package on npm. The fixed releases are 4.2.5 and 2.14.3. The issue is tracked as CVE-2025-32965 and GHSA-33qr-m49q-rxfx.

Was the XRP Ledger itself compromised?

No. The disclosure report says the vulnerability does not affect the XRP Ledger network or codebase, and that no GitHub repositories were compromised. The malicious code was only in the npm package.

Were any funds stolen?

None of the sources we read confirms a theft. The disclosure report said no downstream effects had been reported. Users of the bad versions were still told to assume their wallets were compromised.

What should affected users do?

Upgrade to 4.2.5 or 2.14.3 and move funds to secure wallets. GitHub's advisory also advises rotating keys by assigning a regular key pair, and disabling any master key that may be compromised.

Sources

• XRPL.org: Malicious Supply Chain Compromise in xrpl.js npm Package (April 22, 2025)
• GitHub, XRPLF/xrpl.js: Compromised xrpl.js versions 4.2.1, 4.2.2, 4.2.3, 4.2.4, and 2.14.2, GHSA-33qr-m49q-rxfx (April 22, 2025)
• NIST NVD: CVE-2025-32965 (April 22, 2025)
• Aikido: XRP supply chain attack, Official NPM package infected with crypto stealing backdoor (April 22, 2025)
• XRPL.org: Assign a Regular Key Pair
• XRPL.org: Disable Master Key Pair
• Guardian: SDK Security Audit for EVM and Solana