Safeguard Research Team analysis, July 2026 — In the first six months of 2026 alone, Safeguard's threat research team tracked 214 newly disclosed vulnerabilities and 11 confirmed supply chain compromises across the npm registry — a pace that, if it holds, will make this the worst year on record for JavaScript dependency risk since npm crossed 2 million published packages. The registry now serves more than 3.1 billion downloads a week, and a single compromised transitive dependency can, in the right conditions, put a payload in front of tens of millions of production builds before anyone notices.
This isn't a hypothetical. In September 2025, attackers used a phishing email impersonating npm support to take over the account of a maintainer responsible for debug, chalk, ansi-styles, color-name, supports-color, and more than a dozen other foundational packages with a combined weekly download count north of 2 billion. The injected code targeted browser-based cryptocurrency wallets, rewriting transaction destinations client-side. It was live for less than three hours before the community caught it and npm pulled the versions — but three hours at that download volume is an enormous blast radius, and it set the tone for the twelve months that followed.
Below, we break down what our data shows about which packages carry the most risk right now, why the same names keep resurfacing year after year, and what that means for teams trying to keep a straight face in front of auditors and boards.
The Numbers: What "Most Vulnerable" Actually Means in 2026
"Most vulnerable" gets used loosely in vendor marketing, so it's worth being precise about what we're measuring. Safeguard's analysis draws on three distinct signals across the npm ecosystem from January through June 2026:
- Disclosure volume — new CVEs and GitHub Security Advisories filed against a package or its maintained forks.
- Exposure depth — how many other packages depend on it, directly or transitively, weighted by how deep in the tree it typically sits.
- Exploitation signal — confirmed or suspected in-the-wild abuse, sourced from honeypot telemetry, incident reports, and disclosures from downstream victims.
Ranked by a composite of those three factors, the packages generating the most sustained risk this year aren't obscure fly-by-night modules — they're foundational utilities that sit quietly in tens of thousands of node_modules trees, often several layers below anything a developer consciously chose to install.
This Year's Highest-Risk Packages
Terminal styling and logging utilities (chalk, debug, ansi-regex, ansi-styles, color-name lineage). The September 2025 maintainer account takeover put an entire cluster of these packages on every security team's radar, and the aftershocks are still visible in our data: typosquat variants of the same package names, copycat phishing campaigns targeting other high-download maintainers, and a wave of downstream projects that pinned to pre-compromise versions and never revisited the decision. These packages remain near-universal transitive dependencies of build tooling, which means most organizations carry exposure they never explicitly signed off on.
ua-parser-js. Still recovering, reputationally, from its own October 2021 maintainer-account compromise that pushed a cryptomining and credential-stealing payload to a package with roughly 8 million weekly downloads at the time. It resurfaces on our list this year not because of a new incident, but because a meaningful share of the codebases we scan still resolve to versions published in that compromise window — evidence that "patched years ago" doesn't mean "remediated everywhere."
node-ipc. The package behind the 2022 "protestware" incident, where a maintainer added code that wiped files on machines with Russian or Belarusian IP addresses. It's a useful reminder that not every supply chain risk is a criminal actor — sometimes it's the legitimate maintainer, and no amount of code signing fixes that if the code review process doesn't catch intent.
lodash and its prototype-pollution lineage. Old vulnerabilities, new relevance: prototype pollution bugs from 2019–2020 in lodash.merge, lodash.template, and related functions continue to show up in our scans, almost always because they arrived as a transitive dependency of a transitive dependency, invisible in a typical package.json review.
tar and tar-fs. Path traversal and symlink-following vulnerabilities in npm's most common archive-extraction libraries keep getting patched and keep getting reintroduced through outdated lockfiles, particularly in CI base images that cache dependency layers for months at a time.
semver. A regular-expression denial-of-service vulnerability patched in early 2023 continues to appear in our exposure data because semver is one of the most deeply nested transitive dependencies in the entire registry — practically every build tool depends on it, directly or through several hops.
SheetJS (xlsx). Prototype pollution and ReDoS issues in the spreadsheet-parsing library that never shipped a fix through the standard npm registry channel, forcing consuming teams to either migrate to the maintainer's CDN-hosted releases or accept the risk — a pattern that's created persistent confusion about which "xlsx" a given lockfile is actually resolving.
Why the Same Names Keep Coming Back
Three structural issues explain why this list rhymes so strongly with last year's, and the year before that.
Depth hides risk. A 2026 audit of a typical mid-size Node.js application shows an average dependency tree six to nine levels deep, with the riskiest packages usually sitting three or more levels below anything a developer directly chose. Standard npm audit output flags the vulnerability, but rarely makes clear that the vulnerable function is never actually called by the running application — which is exactly the gap that leads teams to either drown in unactionable alerts or, worse, tune out the tool entirely.
Maintainer account security hasn't caught up to package blast radius. Packages with 500 million-plus weekly downloads are frequently maintained by one or two volunteers without mandatory hardware-key 2FA, corporate email, or any formal incident response plan. The September 2025 compromise succeeded through a garden-variety phishing email — no zero-day required.
Lockfile drift outlives the patch. Every package above has a fixed version available today. The exposure that remains is almost entirely a function of organizations not rebuilding, not re-locking, or intentionally pinning older versions for compatibility reasons and never scheduling the follow-up work.
The Real-World Impact
The consequence of this pattern isn't abstract. Financially motivated actors have shown, repeatedly, that they will target high-download utility packages specifically because the payoff is compromising downstream victims by proxy rather than attacking any one target directly. Wallet-drain payloads, credential harvesters, and cryptomining scripts have all shipped through compromised or typosquatted npm packages in the past eighteen months, and the exploitation window is measured in hours, not days — which is faster than most organizations' patch cadence for anything short of a declared emergency.
For security and platform teams, the practical takeaway is that vulnerability count is the wrong metric to manage against. A single reachable, exploitable finding in a low-download package that's actually invoked in a production code path is a bigger deal than a thousand unreachable CVEs in packages that are present but dormant. The organizations handling this well in 2026 are the ones that have shifted from "how many vulnerabilities do we have" to "which of these can actually be triggered by an attacker, and how fast can we ship the fix."
How Safeguard Helps
Safeguard is built for exactly this gap between vulnerability noise and exploitable risk. Our reachability analysis traces whether a vulnerable function in a package like lodash, semver, or tar is actually invoked by your application's real code paths — so teams stop burning cycles on findings that can never be triggered and focus on the ones that can. Griffin, Safeguard's AI security analyst, continuously correlates new disclosures and supply chain incidents (like the September 2025 chalk/debug compromise) against your live SBOM, flagging exposure the moment it's confirmed rather than waiting for a scheduled scan. Safeguard generates and ingests SBOMs across your build pipeline to give you an accurate, current picture of every transitive dependency — including the ones six levels deep that never show up in a package.json review — and when a fix is available, Safeguard opens an auto-fix pull request with the patched version pre-validated against your test suite, cutting remediation time from weeks to hours. In an ecosystem where the most dangerous packages are also the most invisible, that combination of depth, speed, and precision is what keeps "most vulnerable" from becoming "most exploited."