Private Keys at Risk: XRP Ledger Battles Severe Supply Chain Exploit

The XRP Ledger Foundation has confirmed the discovery of a critical vulnerability in its official JavaScript library, xrpl.js, used by developers to interact with the XRP Ledger blockchain.

According to blockchain security firm Aikido, which detailed the breach in a 22 April blog post, the open-source library was infiltrated by sophisticated attackers who inserted a backdoor designed to steal private keys and gain unauthorised access to cryptocurrency wallets.

The vulnerability specifically affected versions 4.2.1 through 4.2.4 of the xrpl.js library and was first detected by Aikido on 21 April at 20:53 GMT+0, after its monitoring system flagged five suspicious packages published to the NPM (Node Package Manager) registry.

Upon further inspection, Aikido confirmed that malicious code had been embedded, posing a serious risk to any DeFi wallet integrated with the compromised package.

Akido noted:

‘“[T]his package is used by hundreds of thousands of applications and websites making it a potentially catastrophic supply chain attack on the cryptocurrency ecosystem.”

With over 140,000 weekly downloads and widespread adoption across thousands of applications and websites, the incident could have triggered a significant supply chain attack—a threat vector that targets developers and project infrastructure rather than end users directly.

The attackers reportedly deployed multiple versions of the tainted package to obscure the exploit and evade detection.

Aikido’s internal Intel tool, designed to monitor changes in public package repositories like NPM, was instrumental in catching the malicious activity.

While the core XRP Ledger network itself remains unaffected, the breach highlights growing concerns over the security of open-source blockchain tools.

Ripple has since deprecated the compromised packages, and the XRP Ledger Foundation removed them from NPM shortly after the issue was made public.

It remains unclear how many users may have installed or integrated the backdoored versions before they were flagged.

The episode serves as a stark reminder of the risks involved in software supply chains—where trust in a widely used development package can be exploited to infiltrate countless systems in a single, coordinated strike.

XRPL Foundation Confirms Vulnerability, Issues Immediate Fix

The recent breach involving Ripple’s official JavaScript library poses a serious threat to the XRP ecosystem—serious enough for Ripple CTO David Schwartz to issue a public warning. https://

Mayukha Vadari, a senior software engineer at Ripple, also elaborated on the technical aspects of the vulnerability.

While the XRP Ledger itself remains unaffected, the compromised library was distributed through official Ripple channels, exposing users and developers to significant risk.

The potential fallout is considerable: DeFi wallets operating on XRPL collectively hold around $80 million in user funds.

Even a small fraction of that, if compromised, would represent a substantial loss.

In response, the XRP Ledger Foundation, the nonprofit stewarding the XRPL, confirmed the breach and swiftly deployed a fix.

On 22 April, the Foundation released version 4.2.5 of the xrpl.js library to replace the compromised versions.

All affected releases have since been deprecated on NPM, blocking further downloads.

Developers are urged to upgrade to v4.2.5 or fall back to v2.14.3, which was not impacted.

The foundation said:

“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.”

Crucially, the Foundation noted that the XRPL’s core codebase and GitHub repository were not compromised.

A full postmortem report is forthcoming.

Several major ecosystem participants, including XRPScan, First Ledger, and Gen3 Games, confirmed they were unaffected.

XRPScan clarified it uses an older library version that doesn't handle private keys, and Xaman Wallet emphasized it relies on its own infrastructure for key management.

Still, the incident has prompted broader conversations around secure development practices.

Mark Ibanez, CTO of Gen3 Games, credited his team’s avoidance of the compromised versions to “a bit of luck”—but also to good practices.

By committing their pnpm-lock.yaml file to version control, Gen3 Games ensured consistent dependency management, avoiding unexpected updates.

Ibanez highlighted best practices such as avoiding caret versioning in package.json, using Performant NPM (PNPM) when possible, and always committing lockfiles to maintain predictable builds.

Although no major losses have been reported, the incident underscores a growing attack surface: the open-source tools that power blockchain infrastructure.

As attackers shift focus to software supply chains, safeguarding development environments becomes more critical than ever.