Valid provenance, malicious code: what three npm worm waves broke

01Three waves in fourteen weeks, each larger than the last

The first wave hit on 29 April. Between 09:55 and 12:14 UTC, poisoned versions of four official SAP packages appeared on npm. They were mbt, which is used in SAP Cloud MTA builds, and three database packages from SAP’s Cloud Application Programming model.² Together they get about 572,000 downloads a week. The next day the same malicious code showed up in intercom-client on npm and in versions 2.6.2 and 2.6.3 of lightning, the PyTorch Lightning package on PyPI. Wiz and Socket attributed the SAP compromise to a group called TeamPCP.¹

On 12 May the same playbook reached TanStack, Mistral AI and UiPath. Orca called it “the third documented wave from TeamPCP”. It counted 373 malicious versions across 169 npm package names and 2 PyPI packages.³ The third wave began on 4 August, when keyv@6.0.0 was published at 09:35 UTC. Within hours the cache libraries around it followed: cacheable, flat-cache, file-entry-cache and cache-manager.⁴⁵

02What provenance proves, and what it never claimed to

A provenance attestation is a signed statement from the build system: this package was built from this repository, at this commit, by this workflow. Under trusted publishing, the workflow gets a short-lived token from the registry instead of holding a stored one. npm says provenance lets you “publicly establish where a package was built and who published a package”. It also says that provenance “does not guarantee the package has no malicious code.”⁸ This year’s attackers worked in the gap between those two sentences.

In April the warning sign still worked. The SAP database packages were published “without provenance”. The attackers had pushed a modified workflow to a side branch and pulled the publishing token out by hand. SafeDep found why that was possible: the trusted publisher setting “trusted any workflow” in the repository, not just the release workflow on the main branch.² May closed that gap. The TanStack releases came from the legitimate runner with valid tokens, so they “carry valid npm provenance attestations”.³ In August, keyv@6.0.0 carried genuine SLSA provenance tied to its own release workflow, logged in the public Rekor transparency log.⁵ StepSecurity put it in one line: “Provenance proves which commit was built. It cannot prove the commit was authorized.”⁴

03How a worm moves through maintainer tokens

A worm needs two things from each machine it lands on: a way to run, and someone’s right to publish. npm’s install scripts give it the first; a maintainer’s laptop or CI runner gives it the second.

The arithmetic of that loop explains the scale. The first releases came from the maintainer’s compromised GitHub account; StepSecurity says “no long lived npm token was used at all” for them. Everything after that used stolen credentials: “every publish uses the victim org’s own maintainer credentials.”⁴ Releases published with a stolen token carry no provenance. The first, workflow-built releases did.⁵ So a single wave produced both kinds, and no one provenance rule could have caught all of it.

The registry’s own fix is still arriving. In September 2025 GitHub said npm would limit granular publishing tokens to seven days, deprecate classic tokens, “remove the option to bypass 2FA for local package publishing” and disallow tokens by default. It gave no dates.⁹ The tokens the August worm used still carried a bypass_2fa flag set to true.⁵

04Counting the August wave: four trackers, four answers

How big was 4 August? It depends on who you ask, and when. StepSecurity reported 444 packages and 2,212 versions in its update at 18:10 UTC that day.⁴ SafeDep first verified 353 versions across 79 names, then raised its count to 1,684 versions across 420 names in nine organisations. Aikido reported at least 868 packages across 1,381 versions.⁶ On 6 August Singapore’s Cyber Security Agency put it at “over 1,300” versions, with combined downloads of 2 billion a month.⁷ Datadog said only that “hundreds” of packages were hit, some with more than 150 million weekly downloads.⁵

These are snapshots of a moving target, taken at different hours, some by package name and some by version. The Hacker News could not reproduce either broader total from a complete public list, and warned that Aikido’s and SafeDep’s counts “should not be combined.”⁶

05What a company changes, in order

This year’s malicious releases were spotted fast. By 17:40 IST on 4 August, earlier clean releases were back as latest for at least nine of the first packages hit.⁶ The organisations that got hurt were the ones that installed within those hours. That makes time the cheapest control a package consumer has.

Steps 3 and 4 protect you as a consumer; steps 5 and 6 matter if you publish anything, even internal packages. The May wave began with a fork’s pull request that triggered a pull_request_target workflow and poisoned the shared Actions cache. The real release job restored that cache and gave up its publishing token.³ No stored secret was stolen; the pipeline’s own trust was turned against it.