What is an npm supply-chain attack?
An npm supply-chain attack compromises organizations through the open-source packages their developers install from the npm registry. Instead of attacking the target directly, the attacker poisons a dependency - typosquatting a popular name, taking over a maintainer account, or infecting a legitimate package with self-replicating code - and the malicious payload executes on developer endpoints and build systems the moment the package installs.
Also known as: npm malware · dependency poisoning · package supply-chain attack · typosquatting · software supply chain attack
The common attack patterns
Typosquats catch a mistyped install command with a lookalike package name. Maintainer-account takeovers - usually via phishing - push a malicious version of a package thousands of projects already depend on. Install scripts give either pattern immediate code execution: npm runs a package’s lifecycle scripts at install time, before any of its code is ever imported. And 2025’s self-replicating campaigns escalated the model - compromised packages that harvest the developer’s own npm credentials and use them to infect every package that developer maintains, spreading wormlike through the registry.
Why install time is the chokepoint
Lockfiles, audits and scanning in CI all judge a package after it is already on a machine - and an install script has run by then. Blocking at install time inverts that: the package is evaluated against marketplace intelligence, static analysis and policy before npm executes anything, on the developer endpoint where the install actually happens. That is the supply-chain-firewall model Bloom Security applies across npm, the Chrome Web Store and Open VSX - stopping the package at the door rather than investigating it after it moved in.
In the Cyberdis portfolio
Bloom Security blocks malicious packages at install time - distributed by Cyberdis.
FAQ
Common questions.
Is this only a Node.js problem?
No - the same patterns hit PyPI, RubyGems, extension marketplaces and any registry developers install from. npm is the largest and most-targeted registry, which is why the highest-profile incidents, including the self-replicating 2025 campaigns, surfaced there first.
Do lockfiles and npm audit solve this?
They help but are not sufficient. A lockfile pins versions yet a poisoned version can be the one pinned; npm audit flags known vulnerabilities, not fresh malware. Neither stops an install script that executes the moment a developer or build job adds the package.
How do you stop malicious packages at enterprise scale?
Move the control to install time on the endpoint: evaluate every package against marketplace intelligence, static analysis and policy before its code runs, across every developer machine. Bloom Security ships that model as part of its endpoint control plane, distributed by Cyberdis with engineer-led PoCs.
Related explainers: What is an endpoint security control plane?How do malicious browser extensions attack organizations?What is sandbox evasion?
Weighing approaches? Endpoint software governance vs application allowlisting: review everything, or block by default?