DEV Community

Cover image for The Largest NPM Supply Chain Attack Ever and How to Defend Against It
Mohammad-Ali A'RÂBI
Mohammad-Ali A'RÂBI

Posted on

The Largest NPM Supply Chain Attack Ever and How to Defend Against It

#security #npm #node #programming

On September 8th, 2025, the JavaScript ecosystem narrowly avoided catastrophe.

A single phished maintainer account was all it took for attackers to publish malicious updates to 18 of the most popular NPM packages: libraries like chalk, debug, and ansi-regex that collectively get over 2 billion downloads per week. 😱

For about two hours, anyone running npm install or deploying a fresh build could have unknowingly pulled in these compromised versions.

The payload was not just a proof-of-concept. It was a stealthy crypto-drainer, silently swapping wallet addresses during cryptocurrency transactions in web browsers.

If you had a MetaMask wallet open in an app with one of these packages, your funds could have been redirected to the attacker.

This attack is a wake-up call for every developer and organization relying on open source dependencies—which is to say, all of us.

Let's break down what happened, why it matters, and seven practical steps to protect your codebase and your users.

🧵 What Exactly Happened

  • The attackers sent a phishing email to a maintainer, impersonating NPM support and tricking him into entering his credentials and OTP code on a fake website.
  • With access to his account, they published malicious patch versions of widely-used packages. Example: chalk@5.6.1 and debug@4.4.2.
  • The malware was carefully crafted:
    • It only activated in browser environments (typeof window !== 'undefined').
    • It hooked into network APIs like window.fetch and XMLHttpRequest.send.
    • It detected crypto transactions and replaced recipient wallet addresses just before signing.
    • Supported multiple chains: Ethereum, Bitcoin, Solana, and more.
  • Within two hours, security researchers and the NPM team responded:
    • The bad versions were removed from the registry.
    • GitHub advisories were published to alert affected projects.
    • Vercel and other platforms notified teams whose builds had been compromised.

While the direct financial gain was small (~$600 in crypto tracked to attacker wallets), the potential damage was massive.

Imagine this payload in a major fintech app or crypto exchange; millions could have been lost in minutes.

Battle with Jack the Bitcoin Miner in the Black Forest

🛡️ Seven Ways to Protect Your Codebase

Let's call the attacker Jack. He's crafty, patient, and always looking for the next opportunity to slip into your supply chain. 🌲💻🪓

This attack is a textbook example of a supply chain attack—where the weakest link isn't your code, but the dependencies you trust. That's why you should be vigilant about every package you install. Because Jack will be back.

Here are seven practical steps you can take to defend against the next Jack:

1. Pin and Lock Dependencies

Floating versions like ^5.0.0 or latest mean your builds could suddenly pick up malicious updates.

Instead:

  • Commit a package-lock.json or yarn.lock file.
  • Use deterministic installs in CI/CD, because npm install can still update packages within the allowed range. Prefer: 
  npm ci
Enter fullscreen mode Exit fullscreen mode
  • Consider tools like Renovate or Dependabot to manage updates in controlled batches.

Why it matters: If you had a lockfile before Sept 8, you wouldn't have pulled in chalk@5.6.1 automatically.

2. Block Lifecycle Scripts (Postinstall Defense)

Malicious packages often abuse npm lifecycle scripts like postinstall to run arbitrary commands.

Block them by default:

npm install --ignore-scripts
Enter fullscreen mode Exit fullscreen mode

Make it permanent for CI:

npm config set ignore-scripts true
Enter fullscreen mode Exit fullscreen mode

If a trusted package truly needs a script, enable it selectively.

Bonus: This also speeds up your builds!

3. Continuously Scan Your Dependencies

Use Software Composition Analysis (SCA) tools to detect known bad versions:

Run scans in your pipeline and fail builds on critical findings.

4. Use npq Instead of npm

npq is a drop-in replacement for npm that checks the packages for vulnerabilities, deprecated status, and other red flags before installation.

npq install chalk
Enter fullscreen mode Exit fullscreen mode

npq checks for the following:

  • Known vulnerabilities (CVEs)
  • Package age on NPM
  • Package popularity
  • The README file presence

Basically, npq is Snyk Advisor integrated into your install command.

5. Harden Authentication

Maintainers and team members should use hardware security keys (WebAuthn/U2F) for NPM, GitHub, and other critical accounts.

Why?

  • OTP codes (from SMS or authenticator apps) can be phished in real-time.
  • Hardware keys validate the domain origin, blocking phishing attacks like this one.

Golden rule: Never click links in unexpected emails.

Always go directly to the official site.

The compromised maintainer did have a 2FA, but the phishing site entered his OTP in real-time to log in.

6. Watch for Suspicious Diffs

If a tiny utility suddenly ships:

  • Huge obfuscated code blobs
  • Network hooks
  • Wallet or crypto-related code

🚩 That's a red flag.

Use dependency update bots, but review diffs carefully — especially for widely used libraries.

7. Generate SBOMs (Software Bill of Materials)

SBOMs tell you exactly what's in your application.

Generate one during every build:

docker buildx build --sbom=true --push -t your-image:tag .
Enter fullscreen mode Exit fullscreen mode

This command uses Syft under the hood to create an SBOM in SPDX format and upload it to your image registry.
When a package is later reported as malicious, you can search past SBOMs to quickly find and fix affected builds.

⚔️ Defending Against Jack

Jack may be hiding somewhere in the Black Forest, sharpening his code and waiting to strike again.

But you don't have to be an easy target.

By combining strong authentication and proactive dependency management, you can dramatically reduce the blast radius of a supply chain attack.

Discussion

💬 What's your favorite tip for defending against supply chain attacks?

Share it in the comments below.

I'll feature the best one in the next Git Weekly issue and send the winner a free copy of my book, Docker and Kubernetes Security. 📘⚔️

Docker and Kubernetes Security

From supply chain to runtime: build safer images, lock down clusters, instrument logging & audit trails, and stay ahead of emerging threats. The comprehensive guide by Mohammad-Ali A'râbi.

favicon dockersecurity.io

Resources

  • Syft – Generate SBOMs
  • Docker Scout – Scan container images and dependencies
  • Snyk – Dependency vulnerability scanning
  • Trivy – Open-source security scanner
  • npq – npm alternative for security

References

Final Thoughts

The September NPM attack could have been far worse. Thanks to a quick community response, the damage was minimal... this time.

But supply chain attacks aren't going away. Every dependency you install is a potential attack vector.

Stay vigilant, build defensively, and don't let Jack mine your hardware. 🪓

Top comments (0)