Every week, a new npm package turns out to be malicious, hijacked, or quietly backdoored — and most teams find out only after it has already run in their CI pipeline or production build. npm's registry now hosts more than 3 million packages, and a typical modern JavaScript application pulls in hundreds of transitive dependencies it never explicitly chose. That scale is exactly what makes "npm vulnerabilities" such a persistent search — and such a persistent incident category. From the 2018 event-stream Bitcoin-stealing backdoor to the 2025 "Shai-Hulud" self-propagating npm worm, attackers have repeatedly proven that the npm supply chain is softer than the applications built on top of it. Open-source scanners like Aqua Security's Trivy help teams find known CVEs in their lockfiles, but known-CVE matching is only one layer of a much bigger problem. Here's what's actually driving npm risk, how it shows up in the wild, and where detection needs to go further.
What makes npm particularly vulnerable to supply chain attacks?
npm is vulnerable because it optimizes for frictionless publishing and deep transitive dependency trees, not for verifying who is publishing or what runs during install. Any developer can publish a package in minutes with no code review, and npm's postinstall and preinstall lifecycle scripts let a package execute arbitrary code on a developer's machine or CI runner the moment it's installed — before a single line of application code runs. A single popular package like lodash or chalk can sit 3-5 levels deep in a dependency graph, meaning a compromise of one maintainer account can silently reach tens of thousands of downstream applications that never directly required that package. Sonatype's 2024 State of the Software Supply Chain report counted over 512,000 malicious open-source packages discovered that year — a roughly 156% increase over 2023 — and npm consistently accounts for the largest share of any registry because of its sheer publishing volume.
How many malicious npm packages are discovered each year, and is it getting worse?
Yes, malicious npm package discovery has grown roughly every year since 2019, and 2025 accelerated that trend rather than slowing it. Socket's research team has documented tens of thousands of npm packages removed for malicious behavior annually, ranging from credential-stealing installers to cryptominers dropped via postinstall hooks. The clearest inflection point was September 2025, when the "Shai-Hulud" worm compromised over 500 npm packages — including widely used ones tied to maintainers at companies like CrowdStrike's ecosystem and popular utility libraries — by stealing npm publish tokens via phishing and GitHub Actions abuse, then using those tokens to automatically re-publish itself into further packages. It was the first documented self-replicating npm worm at that scale, and it spread faster than most teams' manual review processes could react. Malicious-package volume is now compounding: each compromised maintainer account becomes a distribution vector for the next wave.
What are the most damaging real-world npm compromises to date?
The most damaging incidents share a pattern: a trusted, long-running package gets compromised at the source rather than exploited through a code bug. In November 2018, event-stream — downloaded roughly 2 million times a week — had a malicious dependency (flatmap-stream) quietly added by a new "maintainer," designed to steal funds from cryptocurrency wallets in downstream apps like Copay. In October 2021, ua-parser-js, used by an estimated 8 million weekly downloads including projects at Amazon and Facebook, had three malicious versions published within hours after its maintainer's npm account was compromised, dropping cryptominers and password stealers on Linux, Windows, and macOS. In March 2022, the maintainer of node-ipc deliberately shipped "protestware" that wiped files on machines with Russian or Belarusian IP addresses, affecting any project — including the popular Vue.js CLI tooling chain — that pulled a vulnerable version range. Each case took days to weeks to fully remediate across the dependent ecosystem, because most consumers had no idea they were exposed until public disclosure.
Can Trivy detect these kinds of npm supply chain attacks?
No — Trivy is built to catch known CVEs, not novel malicious packages or in-progress supply chain compromises, and that's by design, not a bug. Aqua Security's Trivy scans your package-lock.json or yarn.lock against an aggregated vulnerability database (pulling from GHSA, NVD, and OSV) and flags dependencies matching a published CVE ID. That model works well for something like a disclosed prototype-pollution flaw in lodash, but it structurally cannot catch a brand-new malicious package, a hijacked maintainer account publishing v2.1.4 an hour ago, or a postinstall script exfiltrating environment variables — because none of that has a CVE yet, and Trivy performs no behavioral or install-time analysis of what a package actually does. Trivy is also fundamentally a point-in-time CLI/CI scanner: it reports what's true when you run it, but it has no native continuous monitoring layer to alert you the moment a dependency you already shipped turns malicious in a later release, which is exactly what happened to ua-parser-js and event-stream consumers. For teams relying on Trivy alone, the gap isn't accuracy on known CVEs — it's coverage of the attack pattern that has caused the most damaging npm incidents on record.
What should teams do differently to catch npm vulnerabilities before they cause damage?
Teams need to shift from periodic CVE scanning to continuous, behavior-aware monitoring of the entire npm dependency graph, not just their direct package.json entries. That means three concrete changes: first, monitor for anomalous publish behavior (a package with 3 years of quarterly releases suddenly shipping four versions in one day, as happened with ua-parser-js); second, inspect install-time behavior such as postinstall scripts and network calls rather than only diffing source against a CVE database; and third, extend visibility to transitive dependencies, since Sonatype and Socket data consistently show that well over 80% of vulnerable or malicious packages enter an application through transitive rather than direct dependencies. Pinning exact versions and using lockfiles helps limit blast radius but doesn't prevent a compromise of a version you've already pinned to and previously trusted — teams still need ongoing re-verification of packages already in production, not just a one-time approval at install.
How Safeguard Helps
Safeguard is built for the gap that known-CVE scanners like Trivy leave open. Instead of matching your npm lockfile against a static vulnerability database once per CI run, Safeguard continuously analyzes your full dependency graph — direct and transitive — for the behavioral signals that preceded incidents like event-stream, ua-parser-js, and the 2025 Shai-Hulud worm: sudden maintainer or publish-cadence anomalies, unexpected install-script network activity, typosquatted package names, and newly introduced obfuscated code in a version bump. Because npm compromises frequently strike packages you're already running in production, Safeguard doesn't stop at the pull request — it monitors packages you've already approved and re-flags them the moment new evidence of compromise appears, closing the detection window that point-in-time scanners leave open by design. For teams that already run Trivy or another SCA tool for known-CVE coverage, Safeguard layers on top to catch the malicious-package and supply-chain-attack category that CVE databases structurally can't cover until after the damage is done. The result is fewer blind spots between "package published" and "compromise discovered" — the exact window attackers depend on.