When the Pipeline Signs Your Malware: The May 2026 Supply-Chain Chain
Three supply-chain compromises in eight days self-propagated through SLSA-attested pipelines. The custodians signed the malware themselves.
There is a way to read the supply-chain incidents of the last two weeks where it all looks like the same story: weak maintainer passwords, lazy 2FA, the usual scolding from the usual security industry voices. That reading is wrong. What happened between May 11th and May 19th is a three-level self-propagating attack where the credentials harvested at each level are the fuel for the next, and where the industry's main defence against supply-chain compromise — SLSA provenance — got bypassed in production by the people it was designed to stop. The custodians shipped the malware themselves, using their own legitimate signing keys, and the cryptography verified beautifully.
The chain starts on May 11th, between 19:20 and 19:26 UTC, in tanstack/configuration. The attacker — a group attributed by StepSecurity as TeamPCP — does not steal a token. They do not phish a maintainer. They use a pull_request_target workflow against itself. The pattern is called a "Pwn Request" and it is documented; the novelty here is what they do with it. They create a fork called zblgg/configuration — deliberately obscured to evade fork-list searches — and open a PR that triggers the target workflow. The workflow runs with the trust context of the base repo, but its inputs come from the fork. The attacker uses that asymmetry to poison the GitHub Actions cache across the fork↔base trust boundary. Then they wait. Days later, an actual TanStack maintainer merges an unrelated, legitimate PR. The release workflow restores the poisoned cache. Attacker-controlled code in the cache extracts the OIDC token directly from the runner's process memory. TanStack's own release pipeline, using TanStack's own legitimate OIDC identity, publishes 84 malicious versions across 42 packages in @tanstack/*. The npm publish workflow itself was never compromised. No credential was stolen. The attacker did not need a key — they got the pipeline to sign on their behalf, and SLSA dutifully attested that the artifact came from where it was supposed to come from. Because it did.
Among the credentials harvested from machines that installed the trojanised @tanstack/* was a GitHub contributor token belonging to someone with write access to nrwl/nx — the Nx Console monorepo. On May 18th, the attacker uses that token to do two things in sequence. First, they push a dangling orphan commit to nrwl/nx: an unreachable commit, not on any branch, invisible to anyone watching the main history but addressable by its hash. Then they publish Nx Console v18.95.0 to the VS Code marketplace. The new version of the extension — the marketplace shows 2.2 million installs — has a single new behaviour: when any workspace opens, it fetches and executes a 498 KB payload from that orphan commit, framed as a routine "MCP setup task" so it slides past anyone reading the diff. The malicious release is live for eighteen minutes, from 12:30 to 12:48 UTC. Eighteen minutes against 2.2 million installs is enough. Among the developers who happened to have the auto-update on during that window are several GitHub employees, and the payload's job is to harvest credentials: GitHub PATs, npm authentication from .npmrc, AWS keys from IMDS and env, HashiCorp Vault tokens, Kubernetes service account secrets, 1Password CLI sessions, SSH private keys, and — a new addition for 2026 — Claude Code configuration files. The next day, GitHub will publicly disclose that approximately 3,800 of its internal source code repositories were exfiltrated. The custodian of the platform got its internal codebase walked out the door by an extension installed in its own employees' editors.
By the time the GitHub disclosure lands on May 20th, the third level is already running. One of the credential sets harvested from the Nx Console window belongs to the atool npm maintainer. On May 19th, between 09:00 and 09:22 UTC — exactly 22 minutes — the attackers' automation publishes 637 malicious versions across 317 packages, including the entire active @antv/* namespace. The payload propagates transitively into echarts-for-react, which has over a million weekly downloads of its own, and from there into roughly 16 million weekly downloads worth of transitive dependents. The same 498 KB harvester runs during npm install on every affected CI runner, with one new trick: it also self-propagates, using the freshly stolen npm tokens to push to additional packages those tokens have write access to. The worm builds its own next wave.
If you opened your laptop this morning and you ship anything Node-shaped, the audit is not optional:
find . \( -name package-lock.json -o -name yarn.lock -o -name pnpm-lock.yaml \) \
-exec grep -lE "@antv|echarts-for-react|size-sensor|timeago|@tanstack" {} \;
Anything that matches needs the lockfile deleted, every direct dependency pinned to a known-good version timestamped before May 11th, and a rebuild from a clean cache. npm audit will not help — there were no CVEs at the time of compromise, just payloads. If your CI ran during any of the three windows (May 11 evening UTC, May 18 around 12:30 UTC, May 19 around 09:00 UTC), treat the runner as compromised: rotate every secret it had access to, check egress for outbound DNS to anything outside your allow-list, assume Action Runner memory was scraped. GitHub has already done part of the cleanup at the registry level — they removed 640 malicious packages and invalidated 61,274 npm granular access tokens that had write permission and 2FA bypass. If yours was in that set it is already revoked; you find out at next publish.
The SLSA break is the bit that should change the conversation, and it is not getting the attention it deserves. SLSA was the industry's bet. The pitch was: cryptographically attest the build's origin from a hardware-rooted identity, verify before install, and the entire class of "the maintainer got pwned" goes away. The TanStack case showed what that bet was actually worth. The attacker did not capture a key. The attacker did not forge an attestation. The attacker got the legitimate pipeline to publish the malicious artifact using its own legitimate identity. The provenance attestation that lands at the npm registry says exactly what it is supposed to say: this artifact was built by TanStack's release workflow, on TanStack's infrastructure, signed with TanStack's key, originating from tanstack/configuration at commit <hash>. All of that is true. The artifact is also malicious, because the workflow that built it executed attacker code recovered from a poisoned cache that survived three days of fork-target trust boundary handling. SLSA proves the build chain. SLSA does not prove the build chain was sober when it ran.
The closest analogue I can think of is chip-and-PIN. The cryptography worked. Cloning a card became hard, so attackers stopped cloning cards and started compromising the issuance process — phantom branch managers, social-engineered issuance, owning the device that authorizes the transaction rather than the card itself. The defenders won the round they thought they were playing, and the attacker moved to a different table. Supply chain underwriters are about to learn this. The next round of cyber-insurance policies — and there will be a next round, very fast — will stop pricing "how many dependencies do you have" and start pricing "what is your blast radius if a single CI/CD workflow is hijacked, what is your detection window, and do you have any maintainer with write access to a top-1000-download package whose machine you have not reviewed in the last 30 days". If the answer to any of those is "I don't know", the deductible will tell you.
Structural defences that actually engage this attack: hardware-bound, time-locked publishing for packages above some download threshold, where the publish requires a fresh physical second factor and an artifact rebuild from source in a clean-room runner. Behavioural anomaly detection on maintainer accounts — banks have had this for fifteen years. Mandatory PR-target workflow isolation that does not share cache scope with base-repo workflows. Within eighteen months at least two of these have to ship on npm and PyPI, or there will be a fourth level to this chain that we have not seen yet. Verify date: end of 2027. If neither registry has shipped publishing-delay or runner-isolation by then, the surface is wide open.
From the attacker's chair — and this is the only seat that matters for defence planning — the playbook is now well-rehearsed and self-funding. Find a project with a CI/CD trust boundary you can poison. Get the legitimate pipeline to publish your payload for you. Harvest the credentials the payload finds on developer machines. Use those credentials to compromise the next project up the chain. Each level signs the next one's artifacts. The world's package managers distribute the payload. The world's CI runners execute it. The world's secret stores cough up the next round of credentials. We don't write malware that exploits anything in a kernel. We don't even social-engineer credentials. We watch the pipeline run. The pipeline does the rest. SLSA was the last serious defence and the pipeline is what signs it. Until the defence lives below the pipeline — in hardware identity, in mandatory timing delays, in runner isolation the workflow author cannot reach — the supply chain isn't the attack surface. It is the attack.
Buy Me a Coffee
Fuel my creativity with a coffee — every sip keeps this blog running!
Support This Blog — Because Heroes Deserve Recognition!
Whether it's a one-time tip or a subscription, your support keeps this blog alive and kicking. Thank you for being awesome!
Tip OnceYou read this far.
Subscribe to understand why cryptography cannot verify if your build chain was sober when it ran.
SubscribeDOGE: DSYxsbfWKAX8wWED9aWeqLEVXU7KihKk6h
Canary: pro-it.rocks-canary-2b9d87dc
