The state of npm supply chain security in 2026

The npm ecosystem has a supply chain problem that is getting structurally worse, not better.

Sonatype's 2026 State of the Software Supply Chain report counted more than 454,600 new malicious open-source packages published in 2025, pushing the cumulative total of packages blocked past 1.233 million. That is a 75% increase in a single year. The attacks documented so far in 2026 have continued that trajectory. By August, the ecosystem had already absorbed incidents affecting packages with combined download volumes measured in the billions per month.

This is not a summary of every incident. It is an honest accounting of how the threat changed in 2026 and what that means for teams that depend on npm.

What changed this year#

Three years ago, a typical npm supply chain attack looked like this: a threat actor registered a name visually similar to a popular package, published a malicious version, and waited for developers to mistype an install command. The blast radius was bounded by how many people made that specific typo.

What happened in 2026 was categorically different. A series of attacks moved through the ecosystem in waves, each one demonstrating a technique the previous one had refined.

Nation-state actors became the primary driver. The debug and chalk compromise in September 2025, in which a threat actor phished the GitHub account of Qix, a maintainer with publish rights to both packages, exposed an estimated 10% of cloud environments within two hours. debug has 300 million weekly downloads. chalk has 400 million. Combined download volume for a two-hour exposure window is difficult to understate. Amazon's July 2026 attribution report connected this attack to North Korea's Sapphire Sleet. The axios compromise on March 31, 2026, 100 million weekly downloads, three hours of exposure, also attributed to North Korea, followed the same playbook: phish a maintainer, publish a malicious version, harvest credentials from developers and CI systems before the registry notices. All four packages in Amazon's attribution, debug, chalk, axios, and typo-crypto, return risk_state: critical in Attestd: full coverage and API responses here.

Group-IB's 2026 supply chain research identified six distinct attacker groups actively targeting npm and PyPI. The sophistication gap between amateur typosquatters and organized threat actors running coordinated campaigns has become the dominant characteristic of the current threat environment.

Self-propagating worms changed the scale equation. The Shai-Hulud worm, first documented in November 2025, eventually compromised 796 packages across multiple attacker waves with a combined 132 million monthly downloads. It worked by stealing npm tokens from infected environments and using them to publish malicious versions of other packages the token had rights to. The ChainDrop attack on August 4, 2026 followed the same model at a larger scale: the attacker compromised the GitHub account of the maintainer behind keyv, flat-cache, file-entry-cache, and cacheable, and within hours the worm had propagated to over 400 distinct packages with combined monthly downloads exceeding 2 billion. Microsoft Threat Intelligence confirmed the ChainDrop attribution to a Shai-Hulud-lineage worm.

Valid provenance stopped being a safety signal. ChainDrop was published with valid GitHub Actions provenance. The attacker had compromised the maintainer's GitHub account, not their npm token, which meant the malicious packages were signed by the same pipeline that signed legitimate versions. Developers who checked provenance got a clean signal. The attack demonstrated that provenance attestations prove the pipeline ran correctly. They do not prove the commits that triggered the pipeline were legitimate.

Blockchain C2 infrastructure arrived. ViteVenom, documented in July 2026, embedded its command-and-control infrastructure in Tron and BSC blockchain transactions rather than static servers. NullReceiver, documented in early August, refined this further by encoding the C2 IP address directly in the bytes of a zero-value Ethereum transfer destination address. The result is infrastructure that cannot be taken down by seizing a domain or blocking an IP. The attacker updates the payload by publishing a new blockchain transaction. Packages already installed on developer machines can be retasked without a new npm publish.

AI-hallucinated package names became an active attack vector. Slopsquatting, the technique of registering package names that AI coding assistants predictably invent, graduated from theoretical risk to documented attack in 2026. Amazon's July attribution report specifically named it. On August 8, a Russian threat actor published over 700 packages using AI-hallucinated names, none requiring install hooks, all triggering on a single require() call.

What the registry did and did not fix#

npm made meaningful progress on several fronts. Granular access tokens replaced the all-or-nothing token model that allowed a single compromised credential to publish every package a user owned. Two-factor authentication is now enforced for maintainers of high-impact packages. Automated scanners flag suspicious packages faster than they did a year ago.

None of these changes prevented the attacks above. The debug and chalk compromise succeeded because the attacker phished the maintainer's GitHub account rather than stealing an npm token. ChainDrop succeeded because it compromised a GitHub account and used the legitimate CI pipeline. Axios succeeded because the attacker changed the email associated with the maintainer's npm account and then bypassed OIDC Trusted Publisher verification by publishing directly via a stolen npm token rather than through the GitHub Actions pipeline.

The pattern is consistent: sophisticated attackers are targeting the humans and the infrastructure around the registry rather than the registry itself. Registry-side defenses are necessary but not sufficient.

What teams are actually doing wrong#

The most common failure mode in 2026 is not running a scanner. Most teams that were compromised by ChainDrop, Shai-Hulud, or the Sapphire Sleet campaigns had some form of dependency scanning in place. The failure was relying on CVE-based scanning as the primary or only signal.

CVE databases record vulnerabilities in legitimate packages. They do not record malicious versions of legitimate packages. [email protected] has no CVE. [email protected] has no CVE. keyv at the ChainDrop-compromised version has no CVE. Every package in the Shai-Hulud campaign has no CVE. A vulnerability scanner that checks the CVE database passes all of them clean.

The supply chain compromise signal and the CVE signal are independent. A package can have a known CVE and a clean supply chain. A package can have a compromised supply chain and no CVE at all. Teams that only check one are blind to the other. This is the structural gap that NVD and CVSS-based tools cannot close regardless of how frequently they update.

The second common failure is treating lockfiles as guarantees. A lockfile pins a specific version. It does not verify that the version has not been tampered with since it was published. ChainDrop published malicious versions of pinned packages. A developer who ran npm ci against a lockfile that included a ChainDrop-compromised version installed the worm.

What the rest of 2026 looks like#

The trends established in the first half of the year are not reversing. Nation-state actors have demonstrated that npm maintainer accounts are a viable initial access vector into enterprise environments. Self-propagating worms have demonstrated that a single compromised account can cascade across hundreds of packages within hours. Blockchain C2 has demonstrated that C2 infrastructure can be made essentially untakeable-down.

The trajectory points toward more attacks at larger scale using more sophisticated techniques. The defense posture that made sense in 2022, run a CVE scanner and trust the registry, does not match the 2026 threat.

A supply chain monitoring layer that checks the compromise status of packages independently from their CVE history, before they reach the install step, is no longer an optional upgrade. It is the check that catches what everything else misses. For teams building this into their pipelines, the CI/CD use case page covers the integration patterns.

For the specific attacks referenced in this post: Attestd's supply chain monitoring covers all major campaigns documented above, including [email protected], [email protected], [email protected], keyv at compromised ChainDrop versions, and ViteVenom packages. All return risk_state: critical with supply_chain.compromised: true. Full API responses and per-campaign coverage are in the individual incident posts on this blog.

The detection ledger showing supply chain detections in real time is at github.com/attestd-io/detection-ledger. The case for why this signal is independent of CVE coverage is at attestd.io/vs-nvd.

---