In April 2025, multiple versions of xrpl.js (the official JavaScript/TypeScript SDK for the XRP Ledger) were published with a backdoor that exfiltrated private keys to an attacker-controlled endpoint. The affected versions included 4.2.1, 4.2.2, 4.2.3, 4.2.4, and 2.14.2, which together covered both the current and legacy support lines. Weekly downloads of xrpl.js sit in the mid-five-figures, smaller than the @solana/web3.js blast radius but still significant across XRPL wallets, exchanges, and dapps.
The attack pattern is now familiar: maintainer credential compromise, version bump, hardcoded exfiltration endpoint. What is interesting is the specific counter-response from the XRPL ecosystem, which moved faster than several prior incidents.
How did the attackers get publish access?
A Ripple-associated npm account was compromised; the exact entry vector was not publicly disclosed but the behavior is consistent with token theft or session hijack.
Ripple's public statement confirmed that the publisher credentials had been compromised and that the compromised token allowed publication of xrpl.js under the legitimate package ownership. The attacker did not create a new package or typosquat; they used the real package. This is the highest-confidence attack class from a downstream consumer perspective because it bypasses every heuristic that looks for new or suspicious package origins.
The five affected versions were pushed over a short window, suggesting automation. Hitting both the 4.x line and the 2.x line shows intent to cover users who might be intentionally pinned to the older major version for compatibility reasons.
What did the payload actually do?
The payload added code paths that captured seeds, secret numbers, and private keys at the point of Wallet construction and sent them to an attacker endpoint.
xrpl.js exposes a Wallet class with constructors like Wallet.fromSeed, Wallet.fromSecret, and Wallet.generate. The poisoned versions modified these constructors to serialize the key material, encode it, and issue an outbound fetch to a hardcoded URL. The URL used a relatively opaque subdomain on a commercial provider, chosen to blend into normal CDN or analytics traffic for casual inspection.
The exfiltration only fired on the server. In the browser, fetch calls to arbitrary origins are often blocked by CORS or CSP; the payload was specifically targeting Node.js contexts where these controls are absent. This matches the observed targeting pattern for SDKs that support both browser and server use: attackers write to hit the server surface because it is where hot wallets and custodial flows live.
How was the attack detected?
Aikido Security (among other researchers) published detection of anomalous package behavior within roughly a day of the first malicious publish.
Detection came from automated pipeline analysis that diffs consecutive package versions, looking for suspicious patterns: hardcoded outbound URLs, new network APIs added to cryptographic code paths, unexpected imports in cryptographic modules. That tooling flagged xrpl.js 4.2.1 as anomalous and the finding was escalated. The XRPL Foundation and Ripple coordinated with npm to unpublish the affected versions and publish clean 4.2.5 and 2.14.3.
The roughly one-day window from first publish to public disclosure is shorter than several prior incidents (polyfill.io took months to publicly surface; Lottie Player took hours but by a manual trigger). Automated behavioral analysis is starting to catch up to attacker tempo for the specific class of "new network egress in a SDK version."
What was the downstream exposure?
Server-side XRPL integrators that installed the malicious versions during the window and then instantiated Wallet objects with live keys exposed those keys.
The blast radius depends on deployment topology. A trading firm running an XRPL market-making bot that upgraded to 4.2.1 and loaded its hot wallet would have exfiltrated that wallet's secret within seconds. A custodial exchange that has hardened its signing infrastructure and only loads keys inside an HSM-fronted service would not have been affected because the Wallet object never holds raw key material in that design.
Post-incident reporting did not surface confirmed multi-million-dollar losses, which suggests two possibilities: the major XRPL integrators had hardened signing, or the window was short enough that attackers did not capture high-value targets before takedown.
What should XRPL teams do in response?
Five things, in priority order.
Rotate any key material that was loaded into a Node.js process using an affected xrpl.js version during April 2025. Move funds to a new wallet. Audit outbound network logs from that period for connections to the disclosed exfiltration endpoint.
Pin xrpl.js to an exact version, commit a lockfile with integrity hashes, and use npm ci in CI and production. Any floating semver that resolved to 4.2.1-4.2.4 or 2.14.2 was a dead man's switch.
Move signing out of the main application process. A dedicated signer service with a minimal dependency surface, strict egress controls (allowlist of XRPL RPC endpoints only), and no user-space code is the structural defense against this attack class. Even if the signer's xrpl.js gets compromised, the network boundary prevents exfiltration.
Enable provenance on npm publishes for any xrpl.js-adjacent packages your team maintains. If you are a downstream project exposing XRPL functionality, use OIDC-based trusted publishing to eliminate long-lived tokens.
Evaluate your dependency monitoring. If you did not hear about this incident within 24 hours, your feeds are not tuned for supply chain. Subscribing to automated behavioral analysis services, ecosystem-specific security advisories, and GitHub security alerts with custom filtering for your dependency list closes the detection gap.
What pattern is emerging across Web3 SDK compromises?
The 2024-2025 sequence of SDK compromises (Solana web3.js, xrpl.js, Ledger Connect Kit, Lottie Player's Web3 drainer) shows a clear attacker playbook: credential phishing, version bump, hardcoded exfiltration endpoint, hit-and-run.
Each incident shares four characteristics. The entry vector is credential theft, not a software vulnerability. The propagation mechanism is legitimate publishing infrastructure, not a registry exploit. The payload is narrow and purpose-built for the specific SDK's use case. The dwell time between publication and detection is measured in hours, not days.
This is a coherent attack economy. Attackers have learned that Web3 SDKs produce immediate, liquid returns and that the defensive surface is underdeveloped. They have also learned that the detection window is short enough that they need to act fast: grab what they can in the hours before yank, then move on. The unit economics favor targeting SDKs with direct key access over, say, generic utility libraries where the payload has to survive to browser runtime.
The defensive implication is that any Web3 team needs a playbook specifically for this scenario. The playbook should include: an always-current inventory of which SDKs are loaded in which services, alerting on version drift, a tested runbook for key rotation in production within minutes, and structural controls that limit blast radius (dedicated signer services, transaction simulation, hardware wallets for hot operations where possible). Treating this as a generic supply chain problem misses the specific shape. It is a repeating, well-understood attack class with a known playbook. Your defenses should be calibrated to it.
How Safeguard.sh Helps
Safeguard.sh's reachability analysis prioritizes xrpl.js as signing-critical code and applies the 60-80% noise reduction to surface it ahead of generic SCA findings in the queue. Griffin AI compares behavioral profiles across package versions and would have detected the new outbound fetch in Wallet constructors independently of public disclosure. The SBOM pipeline captures XRPL SDK usage at 100-level dependency depth across frontend and backend, and TPRM gates critical blockchain suppliers under strict review. Container self-healing rolls back affected signer deployments automatically once anomalous egress is observed, shrinking the exposure window to the detection latency rather than the investigation latency.