A compromised TanStack pipeline signed 84 poisoned packages with valid provenance

Verifying provenance checks identity. It says an artifact came out of the workflow and the repository it names. According to a dev.to post by the developer who writes as phpboyscout, the TanStack versions pushed on May 11 2026 carried exactly that: real attestation, pointing at the real pipeline ^[2]. Whoever held the CI held the signing path with it. A gate configured to reject anything unattested would have let all 84 through ^[16].

"If the pipeline doing the signing is itself compromised, the signature is still perfectly valid. It just now certifies a lie," the author wrote ^[6]. Provenance answers where a package came from; safety of the contents is a separate question ^[8]. The same post calls a signature without diligence behind it "a tamper-proof seal on a poisoned jar" ^[7].

The payload does not wait to be imported. Installing runs it, and it then tries to publish itself from the machine it landed on ^[5].

Three ecosystems already run without that behaviour. Go runs no install or build hooks at all, PHP's Composer runs only your own project's scripts and refuses a dependency's, and Python's wheel format forbids install hooks ^[9]. Cargo's build.rs does the same job at build time instead of install time, and the author says the TrapDoor campaign used it to rifle through keystores on crates.io this year ^[10]. On Rust's position he is blunt: he calls it a smaller, better-policed target, which he says is a different thing ^[11].

Eighty-four versions in six minutes works out at fourteen a minute ^[15]. I would not expect a review step that needs a person to read a diff to fit inside that window. The controls that can are the ones that run unattended on every build.

Registries can sign, scan, attest origin and mandate 2FA on maintainers, and the post's argument is that none of it is a guarantee, because a maintainer gets phished, a CI token leaks, a trusted contributor turns, or a dependency four levels down changes hands ^[12]. Add CI that holds credentials the build never needed, and a dependency tree thousands of strangers deep ^[20].

What the post recommends is cheap and dull. It advises pinning CI actions to commit SHAs, so a moved tag cannot swap code under you, and committing lockfiles. Run cargo-audit, pip-audit, govulncheck, npm audit or OSV-Scanner on every build, the author says, gate the dependency tree, and give every exception an expiry date ^[13]. None of that inspects contents either; it narrows what an attacker can reach and caps how long an ignored finding survives.

The post does not say how TanStack's CI was taken over ^[18]. It is clear about the bind that leaves a consumer in: patch slowly and you are running known-vulnerable dependencies, patch the instant a release drops and you skip the bedding-in that might have caught a poisoned one ^[19]. "There's no setting on that dial that's safe, only trade-offs you have to actually think about," the author wrote ^[14].