---
title: "Valid provenance, malicious code: what three npm worm waves broke"
summary: "How the April, May and August open-source worms put signed releases on npm and PyPI, and the settings that keep the next one out, 29 April to 7 August 2026."
url: https://www.thetechbag.com/blog/npm-worm-valid-provenance-supply-chain
format: Analysis
desk: "Cloud & DevOps"
published: 2026-08-07
facts_checked: 2026-08-07
author: TechBag (The TechBag Journal)
tags: ["npm","PyPI","software supply chain","Shai-Hulud","TeamPCP","SLSA provenance","trusted publishing","GitHub Actions","SBOM","CERT-In"]
cover: https://www.thetechbag.com/blog/covers/npm-worm-valid-provenance-supply-chain.png
---

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

*How the April, May and August open-source worms put signed releases on npm and PyPI, and the settings that keep the next one out, 29 April to 7 August 2026.*

Analysis · Cloud & DevOps · By TechBag · Published 2026-08-07 · Facts checked 2026-08-07 · Canonical: https://www.thetechbag.com/blog/npm-worm-valid-provenance-supply-chain

The short version

- A provenance attestation proves where a package was built and from which commit. It does not prove that anyone authorised the commit, or that the code is safe. In May and again on 4 August, malicious npm releases carried genuine provenance, because the attackers ran each project’s own release pipeline.[3][5][8]
- The three waves grew fast. In late April a handful of SAP, Intercom and PyTorch Lightning releases were poisoned. On 12 May there were 373 malicious versions. On 4 August StepSecurity counted 444 packages and 2,212 versions in under four hours. Other trackers give different totals, and their counts should not be added together.[1][3][4][6]
- The fixes are settings, not purchases. Wait a few days before installing any new release. Install only what the lockfile names. Let one workflow on one branch publish, and keep secrets and shared caches away from code you did not write. If you were hit, remove the worm’s token monitor before you rotate anything.[4][7]

After the Shai-Hulud worm of September 2025, the advice to package maintainers was to stop publishing with stored tokens. Instead they were told to adopt trusted publishing, where the build system proves who it is to the registry, and to attach provenance to every release.[9] In 2026 attackers used that machinery itself. If your company ships software built on JavaScript or Python, three questions follow. What does a signed, attested package still tell you? How does a worm reach your build servers through someone else’s maintainer account? And which settings in your own pipelines would have kept this year’s releases out?

## Three 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.[2] 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.[1]

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.[3] 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`.[4][5]

**Figure: Each wave reached further: four SAP packages in April, 373 versions in May, more than 2,000 in August**

*Open-source package compromises in the Shai-Hulud family, 29 April to 6 August 2026 (UTC)*

| Date | Event | Detail |
| --- | --- | --- |
| 29 Apr 2026 | SAP npm packages | Four packages poisoned between 09:55 and 12:14 UTC; the three CAP releases had no provenance |
| 30 Apr 2026 | PyTorch Lightning and Intercom | lightning 2.6.2 and 2.6.3 on PyPI; intercom-client on npm; same code |
| 12 May 2026 | TanStack, Mistral AI, UiPath | 373 versions, 169 npm names, 2 PyPI packages, with valid provenance |
| 4 Aug 2026 | keyv and the cache libraries | First release 09:35 UTC; 444 packages and 2,212 versions in under four hours |
| 6 Aug 2026 | Singapore's CSA advisory | Treat affected systems as compromised; rebuild and rotate credentials |

Source: The Hacker News and The Register (April); Orca Security (May); StepSecurity, Datadog Security Labs and Singapore CSA (August) · as of 7 August 2026 · Counts are each source's own and use different units; the August figure is StepSecurity's

ReportedWho did it

TeamPCP is the attributed actor for April and May.[1][3] August is less clear. Aikido places it in the Shai-Hulud family, and Semgrep found the same editor hooks, file names and Bun runtime download in the April `lightning` release. The Hacker News says that overlap links the malware but “does not establish” who ran the August campaign.[6]

## What 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.”[8] 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.[2] May closed that gap. The TanStack releases came from the legitimate runner with valid tokens, so they “carry valid npm provenance attestations”.[3] In August, `keyv@6.0.0` carried genuine SLSA provenance tied to its own release workflow, logged in the public Rekor transparency log.[5] StepSecurity put it in one line: “Provenance proves which commit was built. It cannot prove the commit was authorized.”[4]

**Figure: A valid attestation answers where and how a package was built; it is silent on whether the code should exist**

*What npm provenance and trusted publishing establish, read against the April, May and August 2026 releases*

What a valid attestation proves

- The package was built on a named CI system, not on a laptop
- Which repository and which commit it was built from
- Which workflow file ran the build
- That the record sits in a public log anyone can check

What it cannot prove

- That a maintainer reviewed or authorised the commit
- That the workflow, its cache or its runner was clean
- That the maintainer's account was not taken over
- That the package contains no malicious code

Source: npm Docs, Generating provenance statements; Orca Security; Datadog Security Labs; StepSecurity · as of 7 August 2026

Our view

Our view: keep checking provenance, but read it as a trend, not as a verdict. A package that had provenance last release and lacks it now is worth stopping for. That was the April pattern, and StepSecurity says it was also the giveaway in the March axios compromise.[4] pnpm can enforce this: since version 10.21.0, its `trustPolicy: no-downgrade` setting fails the install “if a package’s trust level has decreased”.[10] That catches April-style releases. It would not have stopped a May or August release, which kept full trust.

## How 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.

**Figure: Each infected maintainer becomes a publisher: install, harvest, republish, persist**

*The August 2026 worm's propagation loop, as reconstructed by Datadog and StepSecurity*

1. 01Install runs the payloadA poisoned release adds a `preinstall` hook, so the code runs on `npm install`, before anyone imports it. It fetches the Bun runtime to run itself.
2. 02Harvest every secretIt reads 469 file patterns, the whole environment, the GitHub CLI token and cloud secrets. On Linux GitHub Actions runners it reads secrets out of the runner’s memory.
3. 03Republish as the victimIt lists every package the stolen npm token can write, injects the hook into each one and uploads it. Datadog found tokens set to bypass two-factor checks.
4. 04Persist and punishIt pushes hooks into up to 50 branches that fire in VS Code or Claude sessions. A token monitor runs a payload if the token is revoked. In May, the same kind of daemon was set to wipe the home folder.

Source: Datadog Security Labs (4 August 2026, updated 5 August); StepSecurity (4 August 2026); Orca Security (12 May 2026) · as of 5 August 2026

2,212

malicious npm versions in under four hours on 4 August 2026, by StepSecurity's count

Only 11 packages were seeded by hand. The worm itself republished the other 433 packages and 2,201 versions.[4]

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.”[4] Releases published with a stolen token carry no provenance. The first, workflow-built releases did.[5] 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.[9] The tokens the August worm used still carried a `bypass_2fa` flag set to true.[5]

ReportedOrder matters when you clean up

Revoking a GitHub token is the obvious first move, and here it is the wrong one. The May payload installed a daemon that ran `rm -rf ~/` when it saw its token revoked.[3] For August, StepSecurity says to remove the token monitor first, “since it triggers an attacker payload when the token is revoked.”[4]

## Counting 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.[4] 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.[6] On 6 August Singapore’s Cyber Security Agency put it at “over 1,300” versions, with combined downloads of 2 billion a month.[7] Datadog said only that “hundreds” of packages were hit, some with more than 150 million weekly downloads.[5]

**Figure: Version counts for the same morning range from about 1,300 to 2,212, depending on who counted and when**

*Malicious npm package versions reported for the 4 August 2026 worm, by source, 4 to 6 August 2026*

StepSecurity

2,212 versions

SafeDep (updated count)

1,684 versions

Aikido

1,381 versions

Singapore CSA (over)

1,300 versions

|  | Value (versions) |
| --- | --- |
| StepSecurity | 2,212 |
| SafeDep (updated count) | 1,684 |
| Aikido | 1,381 |
| Singapore CSA (over) | 1,300 |

Source: StepSecurity (4 Aug, 18:10 UTC); SafeDep and Aikido as reported by The Hacker News (4 Aug); Singapore CSA AD-2026-009 (6 Aug) · as of 6 August 2026 · CSA's figure is a floor: it said over 1,300. Aikido's figure carries no time. These are counts of malicious releases, not of infected machines; do not add them together.

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.”[6]

TechBag countTechBag count

The highest version count is 1.7 times the lowest: 2,212 against CSA’s floor of 1,300. Package-name counts spread wider, from 420 (SafeDep) to 868 (Aikido), a factor of 2.1. Every source agrees on the shape: a few hand-seeded carriers, then hundreds of packages republished automatically, all within one working day.[4][6][7]

## What 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.[6] The organisations that got hurt were the ones that installed within those hours. That makes time the cheapest control a package consumer has.

**Figure: Most of the protection is in settings you already own: delay, pin, narrow who can publish, and wall off CI**

*Controls against the April, May and August 2026 waves, in the order to apply them*

Step 1 of 6

1. Check today

Search lockfiles and CI logs for the affected name and version pairs, including transitive dependencies. Datadog and StepSecurity publish the lists.

Source: StepSecurity; Orca Security; The Hacker News on SafeDep's findings; Singapore CSA AD-2026-009; pnpm 10.21.0 release notes · as of 7 August 2026

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.[3] No stored secret was stolen; the pipeline’s own trust was turned against it.

Our view

Our view: if you change one setting this week, make it a cooldown of at least three days on every developer machine and CI job. The cost is real: an urgent security fix also waits, so name the exceptions deliberately rather than turning the policy off. In all three waves, the malicious releases were public knowledge within hours of the first one appearing.[2][3][4] A three-day wait gives the registry, the maintainers and your scanners that time before the code reaches you. A scanner that relies on published advisories cannot do this on its own, because on day zero the advisory does not exist yet.

If you are buying this in India

**Indian companies run the same stacks.** India’s product companies, IT-services firms and global capability centres install from npm and PyPI like everyone else, and packages like `keyv` usually arrive as dependencies of dependencies. Up to 7 August, no report we read named an Indian victim of any of the three waves. The Hacker News’s August report mentions India only for its IST timestamps.[6] No source gives a count of Indian installs, and we will not invent one. CERT-In did warn startups and IT/ITeS firms about the original Shai-Hulud worm in September 2025.[13] We found no CERT-In note on the August worm by 7 August; the government advisory we cite is Singapore’s.[7]

**The SBOM is the Indian lever.** CERT-In’s *Technical Guidelines on SBOM, QBOM & CBOM, AIBOM, HBOM*, Version 2.0, are dated 9 July 2025. They are addressed in particular to government, the public sector, essential services and “organizations involved with software exports and software services industry”. They recommend that government, public sector and essential-services buyers write SBOM requirements into all software purchases. They also define a “transitive” SBOM, one that lists indirect dependencies as well as direct ones.[11] The guidelines are not mandatory.[12] SEBI’s Cybersecurity and Cyber Resilience Framework of 20 August 2024 goes further. As Khaitan & Co summarises it, regulated entities must obtain SBOMs for software used in core and critical operations.[12] A GCC or services firm that keeps a transitive SBOM for every build can answer “did we ship `keyv@6.0.0`?” with a query, not a week of grepping.

**The clock and the cost.** CERT-In’s directions of 28 April 2022 require incidents to be reported within six hours of being noticed. The list includes “malicious code attacks such as spreading of virus/worm” and “unauthorised access of IT systems/data”.[14] A worm on a build runner fits both. The controls in section 5 are configuration and cost ₹0 in licences. If you add a commercial package firewall or a software-composition-analysis tool, compare quotes in INR including 18% GST. Then check whether it can enforce a release-age delay, not only match known advisories.

How we did this

Figures as of 7 August 2026

Written as of 7 August 2026; every source is dated on or before that day. The August counts are each tracker’s own, timed where the tracker gave a time, and never summed; SafeDep’s and Aikido’s are as reported by The Hacker News. The 1.7 and 2.1 ratios are our arithmetic. The CERT-In guidelines were read in full from a copy hosted on a Delhi government site. SEBI’s SBOM requirement is from Khaitan & Co’s summary, not the circular. Counts we saw only in search summaries, including an Elastic estimate of 400-plus packages, are left out.

Spotted an error? Write to us; corrections are published at the foot of the piece.

Sources

1. [The Register, Supply chain attacks hit SAP npm packages, Intercom and PyTorch Lightning (TeamPCP attribution, weekly downloads)](https://www.theregister.com/2026/04/30/supply_chain_attacks_sap_npm_packages/) — 1 May 2026
2. [The Hacker News, SAP-related npm packages compromised by Mini Shai-Hulud (versions, publication window, SafeDep root cause)](https://thehackernews.com/2026/04/sap-npm-packages-compromised-by-mini.html) — 29 April 2026
3. [Orca Security, TanStack npm supply chain worm (Mini Shai-Hulud): counts, attack chain, provenance, wiper](https://orca.security/resources/blog/tanstack-npm-supply-chain-worm/) — 12 May 2026
4. [StepSecurity, ChainDrop npm worm: 444 packages and 2,212 versions, propagation, recommendations](https://www.stepsecurity.io/blog/chaindrop-npm-worm) — 4 August 2026, updated 18:10 UTC
5. [Datadog Security Labs, npm worm compromises popular npm packages (provenance, credential theft, tokens)](https://securitylabs.datadoghq.com/articles/npm-worm-compromises-popular-npm-packages/) — 4 August 2026, updated 5 August
6. [The Hacker News, keyv-linked npm worm poisons hundreds of packages (SafeDep and Aikido counts, npm tag restoration)](https://thehackernews.com/2026/08/keyv-linked-npm-worm-poisons-hundreds.html) — 4 August 2026
7. [Cyber Security Agency of Singapore, AD-2026-009: Ongoing npm supply chain attack affecting Keyv and related packages](https://www.csa.gov.sg/alerts-and-advisories/advisories/ad-2026-009/) — 6 August 2026
8. [npm Docs, Generating provenance statements](https://docs.npmjs.com/generating-provenance-statements) — last edited 4 May 2026
9. [GitHub Blog, Our plan for a more secure npm supply chain](https://github.blog/security/supply-chain-security/our-plan-for-a-more-secure-npm-supply-chain/) — 22 September 2025
10. [pnpm, release notes v10.21.0 (trustPolicy: no-downgrade)](https://github.com/pnpm/pnpm/releases/tag/v10.21.0) — 9 November 2025
11. [CERT-In (MeitY), Technical Guidelines on SBOM, QBOM & CBOM, AIBOM, HBOM, Version 2.0 (copy hosted by the Government of NCT of Delhi)](https://fsd.delhi.gov.in/sites/default/files/FS/circulars-orders/6technicalguidelines_on_bom.pdf) — 9 July 2025
12. [Khaitan & Co, CERT-In's expanded BOM guidelines: preparing for the next phase of cyber regulation (status; SEBI CSCRF)](https://khaitanco.com/thought-leadership/CERT-Ins-Expanded-BOM-Guidelines-Preparing-for-the-Next-Phase-of-Cyber-Regulation) — 22 July 2025
13. [Open Source For You, CERT-In flags Shai-Hulud malware hitting open source npm registry](https://www.opensourceforu.com/2025/09/cert-in-flags-shai-hulud-malware-hitting-open-source-npm-registry/) — 29 September 2025
14. [CERT-In, Directions under section 70B(6) of the IT Act, 2000 (six-hour reporting; Annexure I)](https://www.cert-in.org.in/PDF/CERT-In_Directions_70B_28.04.2022.pdf) — 28 April 2022

Related on TechBag: the [GitHub Enterprise page](https://www.thetechbag.com/github/github-enterprise) covers the platform whose Actions runners and caches sat at the centre of the May wave, along with its secret scanning and dependency review. The [GitLab DevSecOps page](https://www.thetechbag.com/gitlab/gitlab-devsecops-platform) covers dependency scanning and SBOMs built into the pipeline. The [GitHub vendor hub](https://www.thetechbag.com/github) lists the rest of the line.

**Disclosure.** TechBag is a software reseller: it earns a margin when a reader buys through it, including from vendors named here. The analysis is TechBag’s own; no vendor paid for or saw this piece before publication. Facts are labelled reported, TechBag count or our view.

Go deeper on TechBag

- [GitHub Enterprise](https://www.thetechbag.com/github/github-enterprise) — Actions runners and caches, secret scanning and dependency review
- [GitLab DevSecOps Platform](https://www.thetechbag.com/gitlab/gitlab-devsecops-platform) — dependency scanning and SBOMs inside the pipeline
- [GitHub vendor hub](https://www.thetechbag.com/github) — the platform at the centre of the May wave