npm Supply Chain Attacks: How to Protect Your App

npm Supply Chain Attacks: How to Protect Your App

A typical Next.js or Node.js application contains far more code written by strangers than by its own team. Every dependency brings its own dependencies, and a single npm install can pull in hundreds of packages maintained by people you will never meet. For attackers, this is an opportunity: instead of breaking into one company, they compromise one widely used package and let the normal update process deliver their code to thousands of organizations. These supply chain attacks have grown steadily more sophisticated, and in 2026 they reached a new level with self-spreading worms that infect package after package automatically.

What Happened with ChainDrop

In early August 2026, a supply chain worm known as ChainDrop spread through the npm registry. The attack began with the takeover of a maintainer's GitHub account. The attacker pushed malicious files directly to projects' main branches and then published new releases through the projects' own legitimate GitHub Actions workflows. Because the releases were built by the real pipelines, they carried valid provenance information, so provenance checks alone would not have flagged them.

Each infected package gained a preinstall script that ran automatically during installation. It downloaded a separate JavaScript runtime and used it to run an information stealer that collected environment variables, local configuration files, GitHub and npm tokens, CI secrets, and credentials for cloud providers, databases, and services such as Stripe and Slack. With stolen npm tokens, the worm then published infected versions of other packages, spreading further. Reports counted hundreds to more than a thousand affected packages, with billions of combined monthly downloads. The attack built on techniques first seen in the Shai-Hulud worm in 2025.

How npm Supply Chain Attacks Work

Most attacks follow a few recurring patterns:

• Account takeover: attackers steal or phish a maintainer's credentials and publish a malicious version of a legitimate package.
• Install scripts: preinstall and postinstall scripts run automatically during npm install, giving malicious code immediate access to the developer's machine or CI environment.
• Typosquatting: packages with names similar to popular ones wait for someone to make a typing mistake.
• Dependency confusion: public packages with the same name as private internal packages trick build tools into installing the attacker's version.
• Worm propagation: stolen tokens are used to publish infected versions of other packages automatically, turning one compromise into hundreds.

The target is usually not the application itself but the credentials around it. Developer laptops and CI runners hold access to source code, cloud accounts, production databases, and payment systems, which makes them extremely valuable.

What npm Has Changed

The npm registry has tightened security in response. In late 2025, npm disabled the creation of classic tokens and revoked existing ones, limited granular tokens with write access to a maximum lifetime of 90 days, enforced two-factor authentication by default for new write tokens, and replaced long-lived local publishing tokens with short-lived session tokens. Trusted publishing with OpenID Connect allows CI pipelines to publish without storing long-lived tokens at all. These changes reduce the value of stolen tokens, but they cannot stop an attack that starts with a compromised maintainer account and a legitimate pipeline, as ChainDrop showed.

Practical Steps to Protect Your Projects

• Use lockfiles and reproducible installs. Commit your lockfile and use npm ci in CI, so builds install exactly the reviewed versions rather than whatever was published most recently.
• Control install scripts. Disable lifecycle scripts where possible with --ignore-scripts or ignore-scripts=true in .npmrc, and allow them only for the few packages that genuinely need them. Some package managers, such as recent versions of pnpm, no longer run dependency install scripts by default.
• Do not rush new versions. Many malicious releases are detected within hours or days. Waiting a short period before adopting newly published versions, and reviewing dependency updates rather than merging them automatically, avoids many attacks.
• Scan dependencies continuously. Use software composition analysis and malicious package detection tools that look at package behavior, not only known CVEs.
• Limit secrets in CI. Give each pipeline only the credentials it needs, separate build jobs from deployment jobs, and prefer short-lived credentials through OpenID Connect over long-lived tokens stored as secrets.
• Protect developer and maintainer accounts. Require strong two-factor authentication or passkeys on GitHub and npm, and enforce branch protection so code cannot be pushed directly to main without review.
• Keep an inventory. Maintain a software bill of materials (SBOM) so you can quickly answer whether a newly reported malicious package is used anywhere in your systems.

If You Installed a Compromised Package

When a package you use is reported as compromised, act quickly and assume the worst. Treat any developer machine or CI runner that installed an affected version as compromised, even if the package has since been removed. Rotate every credential that environment could access, including npm, GitHub, cloud, database, and third-party API keys. Review logs for unauthorized access and repositories for unexpected commits or releases. Rebuild affected machines and runners from a known clean state, and check the indicators of compromise published by security researchers for the specific attack.

Frequently Asked Questions

What is an npm supply chain attack?

It is an attack in which malicious code is delivered through a package in the npm registry rather than by attacking an application directly. When developers or build systems install the package, the malicious code runs with their access.

What was ChainDrop?

ChainDrop was a self-propagating worm that spread through npm in August 2026. It started with a compromised maintainer account, published infected releases through legitimate CI workflows, stole developer and CI credentials during installation, and used stolen tokens to infect further packages.

Are Next.js applications affected by npm supply chain attacks?

Any application that installs packages from npm can be affected, including Next.js, React, and Node.js projects. The main risk is to developer machines and CI environments during installation, and to any secrets they can access.

Does package provenance protect against these attacks?

Provenance confirms that a package was built by a specific pipeline, which is valuable, but it does not prove the code is safe. In the ChainDrop attack, malicious releases were built through legitimate workflows and carried valid provenance.

Should we disable npm install scripts?

Where possible, yes. Install scripts are a common way for malicious packages to run code automatically. Disabling them by default and allowing them only for packages that genuinely need them significantly reduces risk.

What should we do if we installed a malicious package?

Treat affected machines and CI runners as compromised, rotate all credentials they could access, review logs and repositories for suspicious activity, and rebuild the environments from a clean state.

Conclusion

npm supply chain attacks have evolved from occasional malicious packages into automated worms that can reach thousands of companies within hours. No single measure stops them, but layered defenses do: reproducible installs, controlled install scripts, careful adoption of new versions, continuous scanning, minimal CI secrets, strong account security, and a clear plan for responding when something goes wrong. If you want your Node.js or Next.js projects reviewed for supply chain risk, or your build and deployment pipelines hardened, our team can assess your setup and put these safeguards in place.