The npm supply chain in 2026: what was measured, and what is spam

On 27 August 2026 we queried the counters directly:

Downloads are not people or organisations. This is request volume against the registry, dominated by build pipelines re-pulling. Sonatype states the same outright: downloads are "a consumption signal, not a proxy for unique users".

Registry growth through 2026 runs at roughly 2,470 packages a day net. "Net" matters: in the second half of 2023 the counter fell by 650,000 as npm purged spam. Publishing cannot be separated from deletion in the public data.

The open OSV dataset holds 220,139 records of malicious npm packages. By year of publication:

The 191,420 for 2025 is a trap, and must not be quoted without the caveat. Around 140,000 records fall in four days of November and belong to a single spam campaign: packages with auto-generated names published to inflate reputation scores in a third-party token scheme. The OSV records say so themselves.

Sonatype independently describes the same campaign from a different corpus — 169,538 packages "designed to self-replicate every seven seconds". Two measurements, one campaign.

Cleared of those spikes the picture is smaller and more informative: through 2026, roughly a thousand records a month, rising within the year — 329 in February, 2,984 in August.

For scale: PyPI shows 1,298 records for 2026 against npm’s 10,627 — an eightfold gap.

We analysed all 10,627 names flagged in 2026. The result is unexpected:

Instead of impersonating lodash or express, the dominant pattern is seizing a whole namespace: @antv with 279 records, @servicetitan 141, @cloudplatform-single-spa 122, @mastra 89, @uipath 66.

Those scopes match the year’s known victims exactly. Which follows if the mechanism is: steal access, enumerate everything the account may publish, republish all of it.

Limits of the conclusion: the comparison list held 54 popular names, and "one letter away" is a narrow definition that misses transposition, brand impersonation and compound names. Read this as "in 2026 the threat looks different", not as "typosquatting no longer happens".

After the 2025 attacks npm tightened up, and the sequence matters:

The measures work: the long-lived tokens exploited in 2025 no longer exist.

And yet two of the three worm campaigns of 2026 bypassed them entirely. The mechanism is abuse of trusted publishing via OIDC — precisely the control introduced in place of tokens. The analysis of the May campaign states it plainly: "every previous wave began with a stolen credential; this one did not". Instead of stealing an account it used a misconfigured build workflow and poisoned its cache.

An unwelcome but important conclusion: killing long-lived tokens did not remove the threat but moved it one floor up — into the build systems that now hold the trust.

The June campaign took that logic to its limit: the substituted versions were published carrying valid provenance attestations. The signature was genuine, because a compromised pipeline signed it.

Every event below was cross-checked against OSV records.

• 30–31 March, axios. The compromised version was live for about three hours. The vector was not account phishing: per the maintainers’ own post-mortem, access was gained to the lead developer’s computer through targeted social engineering and remote-access malware.
• 11–12 May. The worm was published on GitHub under a permissive licence — becoming available to anyone. It bypassed the defences via OIDC.
• 1 June, 32 Red Hat packages. The vector was account compromise through a malicious code editor extension. Red Hat’s bulletin names 32 packages, and OSV holds exactly 32. Two independent sources agreeing to the unit.
• 4 August, keyv and related. Package counts differ across sources — "over 400" from some, "over 1,300 versions" from others. They must not be added: one counts packages, the other versions.

And a sobering detail from 2025. The loudest attack of September 2025, reaching packages with hundreds of millions of weekly downloads, was live about two hours and earned its operators, by independent measurement, roughly five cents of ETH plus twenty dollars of a memecoin. The write-up is titled "Oops, No Victims".

Separately on historical events that are routinely retold wrongly: left-pad (2016) was an availability failure, not an attack — no malicious code was ever involved; and xz-utils (2024) has nothing to do with npm — it is a Linux compression library.

For calendar 2025, on npm:

The first three agree within a third — the spread to the rest is definitional, not empirical. OSV counts packages, Datadog counts versions; some include spam and others do not; Sonatype blends all registries.

On the headline "malware grew 75%": that is growth of the cumulative total between two report editions fifteen and a half months apart, not year-on-year growth of new detections, which on a comparable base is about 6%. And by Sonatype’s own taxonomy, 83.4% of that 454,648 is spam and junk rather than an attack payload.

The general rule: every such figure is one vendor’s detection capability on that vendor’s corpus. It is a lower bound, not a rate. Nobody publishes a rate, because the denominator is unknown.

Who actually finds them: in the open 2026 dataset, Amazon Inspector (18,026 reports) and GitHub (6,094). Socket, Snyk and Sonatype contribute nothing to it.

We took 200 packages flagged malicious in 2026 and queried each in the registry. 194 answer 200 and six answer 404. But a 200 does not mean the malware is still there: inspecting sixty of them gives:

We found no case where the malware is still installable. The ten "live" ones are exactly the affected namespaces such as @qlik and @antv, restored after cleanup.

Caveat: sixty of two hundred were inspected, and we did not diff version histories to confirm the specific infected versions are gone. The claim is "removal appears complete", not "removal is guaranteed complete".

The adjacent subject — dependency depth — is covered in a separate article.

Sources: the OSV/OpenSSF open dataset, the npm registry replica, the download counter, the npm 12 changes.