TL;DR: npm supply chain security beyond the vulnerability scanner
npm supply chain security is the practice of making sure every package your JavaScript projects install is legitimate, unmodified and safe, not just free of known vulnerabilities.
- The gap: a classic npm vulnerability scanner matches packages against CVE databases. A malicious package has no CVE, so it passes.
- The proof: in March 2026, a hijacked maintainer account turned axios, with 100M+ weekly downloads, into a malware delivery channel for about three hours.
- The entry point: most npm attacks run through install scripts, which execute the moment you type
npm install. - The fix: detect malicious behaviour as packages are published, not after a CVE appears, and harden how installs run.
On March 31, 2026, thousands of developers ran the most ordinary command in JavaScript: npm install. Some of them pulled a new version of axios, the HTTP client that sits in a huge share of the world’s web applications. Their dependency scanners stayed green. Their builds passed. And a remote access trojan quietly landed on their machines.
Nothing in that story involved a vulnerability. That is exactly why so many npm security programs missed it.
What happened to axios
The attack was simple and patient. According to the axios maintainers’ own post mortem, two malicious versions, 1.14.1 and 0.30.4, were published through the lead maintainer’s compromised account. The attacker did not touch a single line of axios code. They added one new dependency, plain-crypto-js, which ran a postinstall script that fetched a second-stage payload.
Microsoft Threat Intelligence attributed the infrastructure to Sapphire Sleet, a North Korean state actor. The poisoned versions were live for roughly three hours before npm removed them. For any CI pipeline or laptop that installed during that window, three hours was enough.
It was not an isolated case. In September 2025, the Shai-Hulud worm spread across hundreds of npm packages by stealing maintainer tokens and republishing itself. Different technique, same lesson: in npm, trust is inherited automatically, and attackers know it.
Why your npm vulnerability scanner said nothing
Most teams treat npm supply chain security as a vulnerability problem. They run an npm vulnerability scanner, it compares their dependency tree against databases of known flaws, and they fix what it reports. That work matters. It just answers a different question.
| Dimension | Vulnerable package | Malicious package |
|---|---|---|
| What it is | Legitimate code with a bug | Code written to harm you |
| Has a CVE? | Usually, eventually | Almost never |
| When it's dangerous | When the flaw is reachable and exploited | The moment it installs |
| What catches it | A vulnerability database lookup | Behaviour analysis of the package itself |
| Typical response time needed | Days to weeks | Minutes to hours |
A vulnerability database can only describe something somebody has already analysed and catalogued. A malicious package published an hour ago has no entry anywhere. So the scanner returns clean, and clean gets read as safe.
That is the core shift in npm supply chain security: the question is no longer “does this package have a known flaw?” but “is this package doing something it should not?”
Four ways attackers get into your node_modules
- Account takeover. Steal a maintainer’s credentials or token and publish a poisoned version of a package people already trust. This is the axios playbook, and it is the hardest to spot, because the package name is exactly right.
- Typosquatting. Publish
axoisorreqeustsand wait for a typo, a copy-paste from a bad tutorial, or an AI coding assistant to suggest the wrong name. - Dependency confusion. Publish a public package with the same name as one of your internal packages. If your registry setup prefers the public one, you install the attacker’s code.
- Install scripts. The common thread in almost all of the above. npm lets packages run
preinstallandpostinstallscripts automatically, so malicious code executes before anyone imports anything. CISA’s guidance on the axios compromise recommends settingignore-scripts=truefor precisely this reason.
What npm supply chain security looks like in practice
You will not stop every attack with one control. You can make yourself a much harder target with a handful of habits:
- Commit your lockfile and install with
npm ci. Builds should install exactly what was reviewed, never whatever the registry served that morning. - Disable install scripts by default. Set
ignore-scripts=trueand allow scripts only for the packages that genuinely need them. - Scope your internal packages. Unscoped internal names are an open invitation to dependency confusion.
- Check provenance. npm supports provenance statements that link a published package to its source and build. A sudden release without them, from a project that normally has them, is a red flag worth automating.
- Pair vulnerability scanning with malware detection. Keep your npm vulnerability scanner for known flaws, and add detection that analyses what new packages actually do.
The fifth habit is the one most teams skip, and it is the one the axios attack exposed.
Catch the malicious package before it has a name
Xygeni’s Malware Early Warning (MEW) scans new packages on public registries, npm included, as soon as they are published, and analyses their code behaviour rather than waiting for a known signature. When a package is flagged, affected users are notified through email, messaging platforms, or webhooks, and the package is quarantined so you can stop it at your CI/CD guardrails.
Around it, Xygeni’s open source security catches the rest of what the four attack paths above rely on: typosquatting, dependency confusion, suspicious install scripts and unscoped internal npm components. It also covers known vulnerabilities from NVD, OSV and GitHub advisories, prioritised by reachability so you fix what is actually exploitable, with automatic pull requests for the fixes.
MEW is included in the free Developer plan. Start free and scan your first npm projects in minutes.
FAQ
What is npm supply chain security?
npm supply chain security covers every risk introduced through the packages your JavaScript projects depend on: known vulnerabilities, malicious packages, compromised maintainer accounts, typosquatting and dependency confusion. It goes beyond vulnerability scanning to verify that what you install is legitimate.
Does an npm vulnerability scanner detect malware?
Usually not. A traditional npm vulnerability scanner checks packages against databases of known vulnerabilities. A newly published malicious package has no database entry, so it passes unless the tool also analyses package behaviour.
Is npm audit enough?
npm audit is a useful free baseline for known vulnerabilities. It does not detect newly published malware, typosquats or dependency confusion, and it does not tell you whether a vulnerable function is actually reachable from your code.
How do I know if a package is malicious?
Warning signs include install scripts that download or execute remote code, obfuscated code, network calls unrelated to the package’s purpose, a new dependency that the source repository never references, and a release without the provenance the project normally publishes.
