XRPL Supply Chain Attack and How to Block it Using Cloudsmith’s Enterprise Policy Management

Yet another supply chain attack has surfaced, this time using the xrpl library to sneak through malicious packages. xrpl.js is recognised as the recommended npm library for integrating the XRP Ledger (XRPL) with JavaScript/TypeScript applications, and has over 140k downloads a week.

No Cloudsmith Customers Affected

Our security team quickly responded to this threat and found that no Cloudsmith customers are currently using any of the affected versions.

Bogus Package Versions

The attack strategy was to introduce five suspect versions of the library, masquerading as genuine releases.  They inserted a crypto-stealing backdoor by adding malicious code that could leak private keys and silently sign fraudulent transactions.

The five malicious versions are:

• 4.2.1
• 4.2.2
• 4.2.3
• 4.2.4
• 2.14.2

You can get a full and detailed description of the attack from Charlie Eriksen at XRP supply chain attack: Official NPM package infected with crypto stealing backdoor. 

The vulnerability is logged with the CVE Dictionary Entry of CVE-2025-32965.

XRPL Dependencies -  A Critical Security Risk

The XRPL is a Layer 1 blockchain built for payments and asset transfers.  Layer 1 blockchain is the foundational infrastructure of a blockchain. This is where core functions are handled, such as validating transactions, securing the network, and ensuring consensus around transactions and ownership.

The XRPL is used by financial institutions, fintech companies, developers, and startups, mostly for payments, asset tokenization, and building lightweight financial applications.

A supply chain attack on a package integrating with the XRPL can have serious implications. It could expose private keys, hijack transactions, or leak sensitive data, without compromising the ledger itself. If xrpl.js is compromised, any apps using it could unknowingly sign malicious transactions or leak user information, which could result in stolen funds. XRPL dependencies are critical to security.

Blocking the Attack Using EPM

Any security features can and should be tested against real-world threats. Cloudsmith’s Enterprise Policy Management (EPM) includes policy-as-code, meaning custom policies can be written against precise requirements to block known exploits.

For the xrpl.js attack, we know the bogus versions, so it’s easy to write Rego code that checks your repository against the known versions. Cloudsmith can then quarantine the packages if there’s a match against npm packages named xrpl:

package cloudsmith
import rego.v1

# Malicious Versions
malicious_versions := {
    "4.2.1",
    "4.2.2",
    "4.2.3",
    "4.2.4",
    "2.14.2"
}

default match = false

# Check against npm packages called xrpl for affected versions
match if {
	input.v0["package"].format == "npm"
	input.v0["package"].name == "xrpl"
	input.v0["package"].version in malicious_versions
}

For more information on setting up and configuring policy code, see Enterprise Policy Management Example: Quarantine Packages Using Policy as Code.

Try a demo of Cloudsmith and see how it can stop supply chain attacks.

Liked this article? Don\'t be selfish (:-), share with others:   Tweet