npm’s Cryptomining Compromise: The Risks Lurking in Your JavaScript Supply Chain

There’s an old adage about trust: it’s hard to build and easy to lose. Nowhere is this truer than in the world of software development, where we rely on package managers like npm to deliver code that keeps our digital infrastructure humming. But what happens when the trust we place in these repositories is exploited? This week, we got a vivid—and chilling—answer.

Three widely-used npm packages—@rspack/core, @rspack/cli, and Vant—were compromised in a supply chain attack that installed cryptominers on unsuspecting systems. The culprits? Stolen npm account tokens that allowed attackers to publish malicious package versions.

If you’re wondering how this keeps happening, or if the cryptomining angle seems more like a petty theft than grand larceny, let’s dig deeper. This attack reveals vulnerabilities far more significant than CPU theft—it underscores the systemic risks inherent in the software supply chain.

The Attack: A Simple Script, a Complex Problem

The compromised packages did not just steal CPU cycles; they executed a carefully orchestrated attack. Hidden within support.js (in @rspack/core) and config.js (in @rspack/cli), malicious code leveraged npm’s postinstall script to execute automatically upon installation. Like a Trojan horse strolling confidently through the gates, this script fetched a cryptomining payload from an external server and got to work.

Using XMRig, a popular cryptocurrency miner for Monero, the malware cleverly limited CPU usage to 75% of available threads. Why the restraint? Simple: attackers wanted to avoid detection by not pushing systems to their breaking point. To conceal its tracks, the miner was renamed to blend into the filesystem—for example, /tmp/vant_helper in the Vant package.

The attack didn’t stop at cryptomining. It also made reconnaissance calls to http://ipinfo.io/json, collecting victims’ IP addresses, geographic locations, and network details. Such information could be used for tailoring future attacks, revealing how supply chain compromises often serve as beachheads for broader campaigns.

The Victims: Popular Packages, Popular Targets

The attack targeted three npm packages with significant adoption:

@rspack/core: A high-performance JavaScript bundler written in Rust, with over 394,000 weekly downloads.
@rspack/cli: A command-line tool for Rspack, boasting 145,000 weekly downloads.
Vant: A Vue.js UI library for mobile web applications, downloaded 46,000 times weekly.

The popularity of these packages is precisely what made them attractive targets. Developers trust such libraries implicitly, incorporating them into their projects without a second thought. This trust, while essential to the open-source ecosystem, creates a glaring vulnerability when attackers gain access to these repositories.

The Fallout: Lessons from the Aftermath

Both the Rspack and Vant teams responded quickly, issuing new, clean versions of their packages and apologizing to the community. While commendable, their statements underscore the fragility of supply chain security. The root cause? Stolen npm tokens. It’s a reminder that even a single compromised credential can have cascading consequences for thousands of users.

Here’s what developers need to know:

Avoid the Compromised Versions:
- For Rspack, avoid v1.1.7. Upgrade to v1.1.8 or later.
- For Vant, steer clear of these versions:
  - 2.13.3 to 2.13.5
  - 3.6.13 to 3.6.15
  - 4.9.11 to 4.9.14
  - Upgrade to v4.9.15 or newer.
Scrutinize Dependencies: Developers should audit their projects for any inclusion of these compromised versions. Dependency chains can be long and convoluted, so automated tools like npm audit or third-party scanners are essential.
Implement Multi-Factor Authentication (MFA): Both Rspack and Vant admitted that stolen tokens facilitated the attack. Mandatory MFA for npm accounts could have made token theft less consequential, adding another hurdle for attackers.

The Bigger Picture: Why This Keeps Happening

This is far from an isolated incident. Recent supply chain attacks on LottieFiles and Ultralytics similarly exploited package repositories to deploy cryptominers or steal cryptocurrency. What makes npm (and other package managers) so vulnerable?

Low Barriers to Publish: With a valid account token, attackers can publish malicious packages almost as easily as legitimate maintainers.
Implicit Trust in Dependencies: Developers rarely vet dependencies. If a library has thousands of weekly downloads, it’s assumed safe—an assumption attackers are keen to exploit.
Cascade of Trust: Dependencies depend on other dependencies. Compromising a single popular package can ripple through an entire ecosystem.

Defending Against Supply Chain Attacks

The open-source community and individual developers must take proactive steps to reduce their exposure:

Use Dependency Scanners: Tools like Dependabot, Snyk, and Socket can help identify malicious packages and alert you to known vulnerabilities in your dependencies.
Enable MFA: Repository maintainers must protect their accounts with MFA to prevent token theft from becoming a free pass for attackers.
Audit Dependency Trees: Regularly review your projects for outdated or potentially vulnerable dependencies. Automation can help, but manual oversight is invaluable.
Shift Left on Security: Incorporate security checks earlier in the development pipeline. Scanning dependencies before they reach production can mitigate risks.

A Warning, Not Just a Lesson

This incident is more than a reminder to be vigilant—it’s a stark warning about the fragility of the software supply chain. As open-source projects proliferate, attackers will continue to exploit the blind trust we place in these packages. The npm ecosystem, while vibrant and innovative, must address its systemic vulnerabilities.

In the meantime, developers should assume nothing is sacred, nothing is safe, and nothing is beyond scrutiny. After all, trust is earned, not assumed—and in the world of software, it’s one breach away from being lost entirely.