This article details a sophisticated supply-chain attack where an attacker compromised 42 TanStack npm packages by hijacking the legitimate CI/CD pipeline to generate malicious packages with valid SLSA provenance. The attack chain exploited GitHub Actions' `pull_request_target` trigger to poison the cache, which later allowed extraction of OIDC tokens from runner memory during a legitimate workflow execution, enabling the attacker to publish malware signed by the trusted pipeline. No specific CVSS score, affected versions, fixed version, or workaround is provided in the article.
Last week I told you to check provenance. Here’s the attack that breaks that advice. 24 Jun, 2026 In my last post, I argued that the Axios compromise was catchable because the malicious versions had no provenance — they were pushed by hand with a stolen token, while legitimate Axios releases ship through a verified pipeline. Check provenance, catch the attack. I stand by that. But I deliberately left a thread hanging, because there’s a harder version of this problem, and it had already happened six weeks earlier. On May 11, 2026, someone published 84 malicious versions across 42 @tanstack/* npm packages — and every single one carried valid, signed SLSA provenance. To npm’s provenance system and every SLSA checker, these were indistinguishable from legitimate TanStack releases.  This is the attack that should keep anyone building supply-chain defenses honest. What happened The numbers first. Between 19:20 and 19:26 UTC — six minutes — 84 malicious artifacts were published across 42 packages in the @tanstack namespace.  @tanstack/react-router alone sees somewhere around 12 million downloads a week. By the end of the day, over 170 packages were confirmed compromised across npm and PyPI, with more than 400 malicious versions and 518 million cumulative downloads in the blast radius.  But the count isn’t the story. The method is. The packages weren’t published by an attacker who stole credentials — they were published by TanStack’s own legitimate release pipeline, using its trusted OIDC identity, after attacker-controlled code hijacked the runner mid-workflow.  No stolen npm token. No phished maintainer. 2FA was irrelevant because no human credential was ever used. How you forge something you can’t forge SLSA provenance is supposed to be unforgeable — it’s a cryptographic attestation, generated inside the build pipeline, proving a package came from a specific repo and workflow. So how do you get a valid one on malware? You don’t forge it. You get the real pipeline to sign for you. The attacker chained three separate GitHub Actions weaknesses, each one necessary, none sufficient on its own.  The chain, in plain terms: First, they opened a pull request from a throwaway fork against a workflow that ran on pull_request_target — a trigger that runs fork code in the base repository’s security context. That let their fork code poison the GitHub Actions cache with a malicious store.  Then, when a legitimate maintainer’s PR was later merged and the release workflow ran, it restored the poisoned cache, and attacker-controlled binaries extracted the OIDC token directly out of the runner’s process memory by reading /proc/ /mem.  The facts check out and they’re even richer than I remembered. Here’s your second post, written to publish on Bear Blog and link to from Reddit — the deliberate counterpoint to Post 1. Last week I told you to check provenance. Here’s the attack that breaks that advice. In my last post, I argued that the Axios compromise was catchable because the malicious versions had no provenance — they were pushed by hand with a stolen token, while legitimate Axios releases ship through a verified pipeline. Check provenance, catch the attack. I stand by that. But I deliberately left a thread hanging, because there’s a harder version of this problem, and it had already happened six weeks earlier. On May 11, 2026, someone published 84 malicious versions across 42 @tanstack/* npm packages — and every single one carried valid, signed SLSA provenance. To npm’s provenance system and every SLSA checker, these were indistinguishable from legitimate TanStack releases.  This is the attack that should keep anyone building supply-chain defenses honest. What happened The numbers first. Between 19:20 and 19:26 UTC — six minutes — 84 malicious artifacts were published across 42 packages in the @tanstack namespace.  @tanstack/react-router alone sees somewhere around 12 million downloads a week. By the end of the day, over 170 packages were confirmed compromised across npm and PyPI, with more than 400 malicious versions and 518 million cumulative downloads in the blast radius.  But the count isn’t the story. The method is. The packages weren’t published by an attacker who stole credentials — they were published by TanStack’s own legitimate release pipeline, using its trusted OIDC identity, after attacker-controlled code hijacked the runner mid-workflow.  No stolen npm token. No phished maintainer. 2FA was irrelevant because no human credential was ever used. How you forge something you can’t forge SLSA provenance is supposed to be unforgeable — it’s a cryptographic attestation, generated inside the build pipeline, proving a package came from a specific repo and workflow. So how do you get a valid one on malware? You don’t forge it. You get the real pipeline to sign for you. The attacker chained three separate GitHub Actions weaknesses, each one necessary, none sufficient on its own.  The chain, in plain terms: First, t...