npm Supply-Chain Attacks: How Malicious Packages Reach Websites and How to Stop Them

Most modern websites are not written from scratch. A typical Next.js or React site pulls in hundreds of small open-source building blocks from npm, the public library of JavaScript packages. You trust them without reading them, which is normal. A supply-chain attack abuses exactly that trust: the attacker does not break into your website, they poison something your developers install.

What has actually happened

These are the incidents that security vendors and public bodies have described, with the dates they gave.

• 8 September 2025. According to Check Point, a maintainer of widely used packages received an email impersonating npm support, entered his credentials on a fake page, and attackers then published malicious versions of more than a dozen foundational packages, including chalk and debug. The code targeted cryptocurrency transactions in the browser. The packages together are reported to have over two billion weekly downloads.
• Mid-September 2025, the "Shai-Hulud" worm. CISA described a self-replicating attack that compromised more than 500 packages. After it landed on a developer's machine it hunted for tokens and keys, including GitHub tokens and cloud keys, and used stolen npm access to infect other packages that developer could publish.
• 21 to 24 November 2025, "Shai-Hulud 2.0". The security firm mnemonic reported roughly 700 compromised packages or versions and more than 25,000 GitHub repositories created or filled with stolen data. This version ran a script during installation, so even a build server could be hit without anyone opening the code.
• 19 May 2026. TechRadar, citing security firms including Socket, reported that 639 versions of 323 packages were published within about an hour, linked to the same campaign family.

Treat the counts as estimates from the reporting firms; they changed as investigations continued.

How a bad package reaches a business website

Your site is affected in one of three ways:

• The browser. The bad code is bundled into the JavaScript your visitors download. The September 2025 incident aimed at this.
• The build. The bad code runs on your developer's laptop or your build pipeline, stealing passwords and keys. The worms worked this way.
• The server. The bad code runs inside your Node.js application and can read environment variables such as database or payment-gateway keys.

The second route is the one owners overlook. A stolen deployment key can let an attacker change your live site, read your database or run up cloud bills, without touching the website code at all.

What npm and GitHub changed in response

GitHub, which runs npm, said in September 2025 it would tighten publishing rules, including requiring two-factor authentication for local publishing and shortening token lifetimes. Its changelog states that on 9 December 2025 all classic npm tokens were permanently revoked, that a normal npm login now issues a session token lasting two hours, and that write tokens made for automation expire after at most 90 days. GitHub recommends trusted publishing, which lets a build system prove its identity without a stored publishing token. These steps make theft of publishing rights harder; they do not make every package safe.

Practical protection, in order of value

1. Commit the lockfile and install from it. A lockfile (package-lock.json) records exact versions. Using npm ci in builds installs those exact versions instead of whatever is newest.
2. Do not auto-update on live builds. Update dependencies deliberately, review what changed, and wait a few days after a new release unless it fixes a known flaw.
3. Turn on two-factor sign-in everywhere. That means GitHub, npm, your hosting dashboard and your email. CISA's advice after Shai-Hulud was phishing-resistant multi-factor authentication. See two-factor authentication for the basics.
4. Keep secrets out of builds that do not need them. Give each pipeline only the keys it requires, and rotate keys quickly if a suspicious package was ever installed.
5. Use fewer dependencies. Every package is a door. Ask whether a three-line function needs a library.
6. Turn on alerts. Dependabot-style security alerts and secret scanning on GitHub catch known bad versions and leaked keys.
7. Review install scripts. Some packages run code when installed. Teams can disable these where they are not needed, though a few legitimate packages rely on them, so test first.
8. Plan your response. Know in advance who rotates keys and who checks the site if an advisory lands.

When it does not matter much

A simple brochure site with no logins, no payments and a couple of trusted dependencies has little for an attacker to steal, and a locked lockfile plus two-factor sign-in covers most of the risk. The exposure grows with stored customer data, payment keys, admin panels and many contributors. If your site handles payments, our post on payment page script rules covers a related risk, and our small business security basics list the account-level habits.

How we approach it at VS Tech Builders

For client work built on Next.js, we recommend a committed lockfile, deliberate dependency updates and separate keys for each environment. If you already have a site or app and no one knows what it depends on, we can review the dependency list and set up CI/CD so builds are repeatable. Contact us to ask for a review, or read more on our tech news hub.

Sources

Checked on 3 November 2026. Technology changes quickly; always confirm details with the official source before you act on them.

• The Great NPM Heist: September 2025 — Check Point Blog
• Widespread Supply Chain Compromise Impacting npm Ecosystem — CISA
• Advisory: Shai-Hulud 2.0 supply chain campaign rapidly spreading through npm packages and GitHub — mnemonic
• npm classic tokens revoked, session-based auth and CLI token management now available — GitHub Changelog
• Mini Shai-Halud hackers publish over 600 compromised npm packages — TechRadar

Frequently asked questions

What is an npm supply-chain attack?

It is an attack where criminals publish or tamper with a package that many websites and apps depend on, instead of attacking each site directly. When developers install or update the package, the malicious code runs on their computers, build servers or inside the site itself, and can steal passwords, keys or customer payments.

Is my website at risk if I use WordPress or Shopify and not npm?

The npm incidents mainly affect sites and tools built with JavaScript packages, such as Next.js or React projects. WordPress and Shopify have their own supply-chain risk through plugins and apps. The principle is the same: install fewer add-ons, keep them updated from trusted sources and protect admin accounts with two-factor sign-in.

How do I know if a bad package was installed on my project?

Ask your developer to check the lockfile against the published advisories, look at recent dependency changes and review the build logs. Also look for unexpected repositories or workflows in your GitHub account. If a flagged version was installed, rotate every key and token that machine or pipeline could reach.