NPM under attack: compromised JavaScript packages, crypto addresses hijacked. Warning from Ledger’s CTO: over 1 billion downloads exposed

The CTO of Ledger, Charles Guillemet, reported on X a supply chain attack involving widely used NPM packages. 

According to a report by CoinDesk, some compromised versions – totaling over 1 billion downloads – include code capable of replacing, “on the fly,” destination addresses in crypto transactions, redirecting funds to wallets controlled by attackers. This scenario aligns with supply chain protection recommendations published by industry organizations like OWASP, which highlight how supply chain compromises can have large-scale impacts.

According to the data collected by our threat intelligence team in the last 24 hours, indicators of compromise have emerged consistent with the technique described in multiple repositories and build pipelines. Analysts we collaborate with also emphasize that the scope of the incident is amplified by transitive dependencies and the size of the registry: the NPM registry hosts over 2 million packages, increasing the likelihood of propagation of a compromised module.

Attack Mechanism: Addresses Changed “On the Fly”

That said, the malicious payload activates both during on-chain operations and at the moment of transaction generation or signing. In practice, the malware intercepts the recipient address and replaces it with one belonging to the malicious actors. The user, seeing an apparently “clean” screen, might not realize that the final transaction sends the funds to a different address – a dynamic also confirmed by The Block. It should be noted that the manipulation is aimed at remaining invisible until the last confirmation step.

Involved packages: numbers, provisional names, and distribution

Initial analyses indicate that the compromise occurred by exploiting the account of a maintainer with access to widely used libraries. Among the names circulated is, for example, the package error-ex – whose official profile can be viewed on npmjs.com – although the official lists are still being updated. The impact is amplified by the cascading effect due to dependencies: a single compromised module can spread to hundreds of projects, thanks to import chains. Indeed, the modular nature of JavaScript code makes it easier for the problem to spread when dependencies are deeply nested.

• Exposure scale: over 1 billion cumulative downloads of potentially at-risk versions.
• Vector: publications on NPM through stolen credentials or compromised pipeline.
• Scope: core libraries used in web projects and wallets.

The official lists of affected packages and versions are partial; it is advisable to monitor NPM advisories and maintainer repositories. However, until definitive communications are made, it remains prudent to consider the entire dependency chain at risk.

Impact on users and businesses

• Direct crypto theft following the sneaky replacement of the address.
• Application integrity compromised in dApp, extensions, and desktop/web wallets.
• Reputational risk for projects that integrate contaminated packages.

What to Do Immediately: Emergency Checklist

For end users (crypto)

• Prefer wallets that clearly display transaction information (screen and clear signature – Clear Signing), verifying the address and amount on the device before confirming. For practical guidance, see our guide on checking hardware wallets.
• Avoid blind signing and limit the use of unverified QR codes.
• Compare the displayed address with a secure copy and use whitelists for frequent recipients.

This precaution is crucial because confirmation on a hardware wallet shows the data that is actually being signed, making any address substitution by the host software evident. In this context, verification on the device’s screen reduces the likelihood of error or upstream manipulation.

For development teams

• Temporarily suspend automatic updates of critical dependencies.
• Perform auditing and rollback of the versions published during the suspicious period.
• Rotate NPM tokens and make 2FA activation mandatory for maintainers and releasers (see here).
• Enable provenance systems for publications and sign build artifacts.

How to verify if a project is exposed

Quickly identifying suspicious dependencies and installed version ranges is crucial: timely reconnaissance limits the domino effect in pipelines.

# List installed versions and dependency chain

npm ls error-ex

# Check known vulnerabilities and advisories

npm audit –production

npm audit –json > audit.json

# Block non-deterministic updates in CI

npm ci –ignore-scripts

# Set a stricter audit threshold

npm config set audit-level=high

# Check available versions and publication dates

npm view error-ex versions –json

npm view error-ex time –json

In CI contexts, setting ignore-scripts=true helps reduce the risk of executing malicious post-install scripts. That said, it is advisable to establish a reproducible baseline right away to avoid unexpected deviations. For an extended checklist on CI verifications, refer to our page on supply chain best practices.

Strengthening the supply chain: recommended technical defenses

• Use a deterministic lockfile (package-lock.json) and deploy with npm ci to ensure reproducibility.
• Enable 2FA on NPM for publications and critical access, using tokens with limited scopes (automation vs. publish).
• Implement mandatory code review and use an isolated CI pipeline with artifact signing.
• Adopt provenance systems, referring to the official documentation on npm package provenance and standards like SLSA.
• Use scanning tools and controlled updates, such as Dependabot, Renovate, and sigstore/cosign, where applicable.
• Apply the principle of least privilege for the accounts of maintainers and release bots.

Timeline and Status of Investigations

The alert was made public today, September 8, 2025, and verifications are currently underway. Official advisories and updated lists of compromised packages and versions will be released progressively. Therefore, it is advisable to maintain a cautious approach, suspending non-essential updates until indicators of compromise are consolidated. Pending further feedback, the priority remains to contain exposure and carefully document every change.

Critical Angle: A Chain of Trust Still Fragile

The open source supply chain remains vulnerable when account access and publishing pipelines are not adequately protected. The issue becomes particularly pressing when, in 2025, numerous publications still occur without the systematic adoption of measures such as 2FA, provenance, and rigorous reviews. 

As long as trust is taken for granted, every project will continue to be exposed to the risk generated by others. Yet, even small improvements in processes can significantly reduce the attack surface.

The Point

This episode highlights how critical supply chain security is in open-source software. As long as investigations are ongoing, the priority will be to limit attack surfaces, carefully verify transaction data on screen, and consolidate publishing processes through the adoption of 2FA, lockfile, and provenance systems. 

The transparency of advisories, as noted by numerous experts, will be crucial in measuring the real impact and restoring trust in the ecosystem. In this context, adherence to best practices remains the only immediate safeguard.