DEV Community

Cover image for đŸ”„ The Night npm Caught Fire: Inside the 2025 JavaScript Supply-Chain Meltdown 📉
MUHAMMAD USMAN AWAN
MUHAMMAD USMAN AWAN

Posted on

đŸ”„ The Night npm Caught Fire: Inside the 2025 JavaScript Supply-Chain Meltdown 📉

🚹 Recent NPM Supply Chain Attacks — What Happened, Why It Matters, and How to Protect Yourself

Open-source JavaScript libraries are under siege. In late 2025, multiple high-impact attacks targeted npm packages—affecting everything from small utilities to widely used React/Next.js dependencies. These incidents exposed thousands of secrets, compromised maintainer accounts, and demonstrated just how fragile the JavaScript supply chain can be.

This post breaks down what happened, how these attacks worked, and what developers can do to protect themselves going forward.


1. The Wave of NPM Attacks in 2025

1.1 The September 2025 Chalk/Debug Attack

In September 2025, attackers breached maintainer accounts and injected obfuscated crypto-stealing code into popular packages—including:

  • chalk
  • debug
  • ansi-regex
  • color-name 
and others.

These infected versions silently redirected cryptocurrency transactions to attacker wallets before being removed by npm.

This attack was especially alarming because these packages are downloaded billions of times per day, showing how a single compromised dependency can ripple through the entire ecosystem.


1.2 The Shai-Hulud Worm (September 2025)

Soon after, a self-replicating npm worm named Shai-Hulud emerged.

Attackers compromised real developer accounts and pushed backdoored versions of trusted packages such as:

  • ngx-bootstrap
  • ng2-file-upload
  • @ctrl/tinycolor

Each trojanized update:

  • Stole credentials (GitHub tokens, npm tokens, cloud keys)
  • Uploaded secrets to public GitHub repos
  • Used stolen npm tokens to infect more packages

It spread wildly—over 500 packages were compromised before the malware was fully neutralized.


1.3 Typosquatting Malware Wave (October 2025)

In October, security researchers uncovered a set of typosquatted packages designed to mimic popular libraries:

  • react-router-dom
  • ethers.js
  • nodemon
  • zustand

These fake packages contained multi-stage infostealers that:

  • Triggered fake CAPTCHAs
  • Installed a hidden 24MB payload
  • Extracted:

    • System passwords
    • Browser cookies
    • OS keychain secrets

They even launched hidden terminals to run stealthily—showing how dangerous postinstall scripts can be.


2. The Latest Attack: Shai-Hulud 2.0 (Nov 2025)

A second, even larger wave landed in late November 2025.

2.1 What Was New?

Attackers again targeted maintainer accounts for major projects, including:

  • Zapier
  • ENS Domains
  • PostHog
  • Postman

Once inside, they published trojanized npm versions with a preinstall script that:

  1. Downloaded and executed the Bun runtime
  2. Ran a 10MB credential-stealing payload
  3. Scanned for secrets using TruffleHog
  4. Uploaded stolen data to GitHub repos labeled: “Sha1-Hulud: The Second Coming”

Victims’ machines effectively became secret-exfiltration bots.

2.2 Scale of the Impact

  • >800 compromised npm packages
  • ~30,000 GitHub repos created to store stolen credentials
  • 400,000+ secrets leaked
  • 60% of exposed npm tokens were still active
  • Included a destructive wiper that could delete a user’s home directory

2.3 React / Next.js Ecosystem Impact

Packages like:

  • @posthog/nextjs
  • @posthog/nextjs-config


were among those trojanized, meaning even common React/Next.js analytics integrations were potential entry points.


3. How Supply-Chain Attacks Like These Work

3.1 Maintainer Account Takeover

Phishing or stolen credentials allow attackers to publish malicious updates to legitimate packages.

3.2 Typosquatting

Creating packages that look almost identical to popular ones:

  • react-router-dom.js vs
  • react-router-dom

3.3 Dependency Confusion

Uploading a public package with the same name as a private package, tricking CI pipelines into pulling the attacker’s version.

3.4 Malicious Lifecycle Scripts

npm executes:

  • preinstall
  • postinstall

scripts automatically.

Attackers use these moments to:

  • Run binaries
  • Download malware
  • Exfiltrate secrets
  • Launch hidden background processes

3.5 Why npm Is Vulnerable

npm install = full remote code execution
Anything inside a lifecycle script runs with developer privileges.


4. Why These Attacks Matter

Supply-chain compromises can:

  • Backdoor corporate systems
  • Steal cloud API keys
  • Hijack GitHub repos
  • Infect entire CI/CD pipelines
  • Spread automatically across dependency trees

Even “small” utilities like chalk can have billions of weekly downloads—so the blast radius is enormous.

Shai-Hulud 2.0 even contained a wiper capable of deleting entire user directories if disrupted.


5. How to Protect Your Projects

5.1 Use Lockfiles & Deterministic Installs

Always:

  • Commit package-lock.json or yarn.lock
  • Use npm ci or yarn --frozen-lockfile in CI

This prevents surprise updates to malicious versions.


5.2 Disable or Restrict Lifecycle Scripts

Options:

  • npm install --ignore-scripts
  • Yarn’s script-blocking mode
  • pnpm’s blocked-by-default script policy
  • Tools like LavaMoat to whitelist allowed scripts
  • Deno requires explicit --allow-scripts permissions

5.3 Use Secure Runtimes and Sandboxing

  • Deno → Secure-by-default, no file/network access without flags
  • Bun → No sandbox, but has a built-in CVE scanner
  • pnpm → Safer module isolation, content-addressable store

5.4 Protect Your Registry Accounts

  • Enable 2FA on npm
  • Rotate tokens
  • Use scopes + short-lived tokens
  • Adopt npm provenance / trusted publishing

5.5 Audit Dependencies Regularly

Use:

  • npm audit
  • Snyk
  • OSS Index
  • GitHub security advisories

Watch for:

  • Sudden version jumps
  • New maintainers
  • Recently transferred packages
  • Strange install-time behavior

6. Comparing npm, pnpm, Bun, and Deno for Security

Feature npm (Node) Deno Bun pnpm
Default permissions Full I/O, network access Sandboxed by default Full access Full access
Lifecycle scripts Enabled by default Disabled unless allowed Enabled Blocked unless approved
Lockfile package-lock.json No central lockfile bun.lockb pnpm-lock.yaml
Vulnerability scanning npm audit None built-in Built-in scanner Relies on npm tools
Registry npm registry No global registry (URL imports) npm registry npm registry

7. Final Takeaways

The 2025 npm attacks were a wake-up call.

They showed that:

  • Dependency installs = potential RCE
  • Even trusted packages can be compromised
  • Maintainer accounts are high-value targets
  • Entire ecosystems (React, Next.js, tooling libraries) are vulnerable

The path forward:

  • Lock down installs
  • Restrict scripts
  • Minimize dependencies
  • Adopt secure runtimes
  • Audit aggressively

There’s no silver bullet.
But layered defenses make catastrophic supply chain attacks far less likely.

Thanks for reading! 🙌
Until next time, đŸ«Ą
Usman Awan (your friendly dev 🚀)

Top comments (2)

Collapse
 
vectorialpx_0cfc7e8063981 profile image
vectorialpx

Peer reviews in the team are also a must, checking all guardrails are in place and (thank you for this post) having awareness regarding code-security future and AI capabilities (this amplified the attacks a lot).

Collapse
 
usman_awan profile image
MUHAMMAD USMAN AWAN

Absolutely — peer reviews are essential for keeping guardrails solid and catching issues early. And you're right, with AI evolving so fast, staying aware of new security risks is more important than ever. Thanks for calling it out! 🙌