The npm Supply Chain Is the New Attack Surface

Every time you type npm install you are running code from an average of 1,400 strangers on a computer that holds your secrets.

The number is not a metaphor. A 2023 analysis of the top npm packages found that a single install can pull in over 1,000 transitive dependencies, each maintained by a different person, hosted in a different repository, with a different update cadence and a different security posture. Some of those packages are abandoned. Some have a single maintainer who has not committed in three years. Some have been transferred to a new maintainer through a process that involves exactly one email confirmation.

The trust assumption underneath every install command is that this stack of strangers, taken as a whole, is not actively working against you. Most days, that assumption holds. The days it does not, the consequences are extraordinary.

The trust assumption underneath every install

npm, like PyPI, RubyGems, Maven Central, Crates.io and the other major package registries, is built on a model of radical permission. Anyone can publish. Anyone can name a package whatever they like. Anyone can claim a maintainer seat on an existing package. The install command, by default, fetches the latest version. The build system, by default, runs the package’s install scripts, which can execute arbitrary code on your machine.

This is not a bug. It amounts to the design. The model that made the JavaScript market the largest software supply chain in history serves as the same model that turns a typo into a backdoor. The trade was not made in ignorance. It was made in 2010, by people optimising for install speed and onboarding friction, and it has not been revisited at the architectural level since.

Recent supply chain attacks and what they had in common

Look at the supply chain attacks of the last three years. xz utils, the backdoor discovered in March 2024 after two years of patient social engineering of a single overworked maintainer. ua-parser-js, hijacked in October 2021 through a maintainer account takeover, shipped cryptocurrency stealing code to millions of installs. event-stream, the 2018 attack that added a Bitcoin stealing payload to a popular library. The colours.js and faker.js incidents in January 2022, where the author of two widely used libraries deliberately corrupted them in protest. The node-ipc malware in March 2022 that wiped Russian and Belarusian machines. The tj-actions/changed-files supply chain attack in March 2024 that exposed secrets from thousands of CI pipelines.

Every one of these attacks is different in mechanism. Every one of them amounts to the same in pattern. A package with a small or single maintainer. A maintainer who is overworked, underpaid, and the de facto security boundary for an entire market. An attacker who knows this and exploits it, patiently, over months.

Why the npm maintainer model is structurally vulnerable

The npm maintainer model is a hobbyist model scaled to industrial load. Most popular packages on the registry are maintained by one or two people, in their spare time, often as a portfolio project that grew beyond anyone’s expectations. The financial incentive to maintain a critical piece of infrastructure is roughly zero. The reputational incentive is negative: the maintainer serves as the person who gets blamed when the package breaks.

There is no good way to fix this without changing the economic structure of open source. GitHub’s sponsored maintainers program, the OpenSSF’s Alpha Omega project, the various foundation grants, all of them are partial. The ratio of money flowing through the market to the load placed on individual maintainers is still deeply asymmetric.

In the meantime, the structural vulnerability persists. Every package with a single maintainer is a single phishing email away from a backdoor.

The dependency depth problem

You install one package. The package’s package.json lists its dependencies. Each of those packages lists its dependencies. Each of those lists its dependencies. By the time the resolver finishes, the install graph contains hundreds or thousands of packages, most of which you have never heard of, none of which you have reviewed.

The depth matters because the attack surface scales with it. A transitive dependency three levels down is, from a code review perspective, almost invisible. A vulnerability in a deeply nested utility will not show up in a top level review of the packages you actually use. It will, however, be in your production binary and your CI logs and your build cache.

The honest answer to “is your supply chain secure” is almost always “I have no idea, and neither does anyone else.”

Typosquatting, dependency confusion, and account takeover

Three patterns account for most successful registry attacks. Typosquatting: an attacker publishes a package with a name one character different from a popular one, hoping someone mistypes. Dependency confusion: an attacker publishes a package with the same name as an internal package, but with a higher version number, exploiting the resolver’s preference for the higher version. Account takeover: an attacker phishes or credential stuffs a maintainer account and publishes a malicious update to a legitimate package.

All three are well understood. All three have been used in real attacks against real companies. All three are unsolved at the registry level, because the registry’s design privileges publishing speed over publisher verification.

What realistic defenses look like

You cannot fix the supply chain. You can, however, reduce the blast radius when it fails. The pattern that works in 2026 looks like this. Pin all production dependencies to exact versions, including transitive ones, with a lockfile checked into the repository. Run a software bill of materials generator on every build. Run a vulnerability scanner on every build, and fail the build on critical issues. Run integrity checks on every install. Use sigstore or a similar signing scheme for the most critical internal packages. Audit your top 20 dependencies manually, every six months, and look for signs of maintainer fatigue, single points of failure, and suspicious recent activity.

This is not a small amount of work. It is also not optional. The companies that did not do this work in 2024 are the companies that ended up in the post incident report in 2025.

What an org should actually do this week

1. Run npm ls --all (or the equivalent in your language) on your top three production repositories. Count the dependencies. The number will be larger than you think.
2. Pick the five packages at the deepest levels of the tree and read their source. If you cannot explain what they do in one sentence, that is a finding.
3. Identify which of your dependencies are maintained by a single person. Flag those for extra review.
4. Turn on integrity checks in your package manager. Most default to off.
5. Pin your CI actions to a specific commit hash, not a tag.
6. Set up alerts for new versions of your top 50 dependencies. The supply chain attacks of 2024 to 2026 all had a tell: a new version published by a different maintainer or at a strange time.

The bottom line

The npm registry is not going to fix itself. The maintainer model is not going to be properly funded in the next five years. The dependency tree is not going to get shallower. The attackers are not going to get less patient.

What you can do is treat your supply chain like a third party vendor relationship, with the same review and monitoring rigor. The companies that do this will keep shipping. The companies that do not will read about themselves in a future blog post titled “how we lost a week to a six line patch in a library none of us had heard of.”