Loading today’s stories
Build1 distinct publisher3 min readPublished
Akamai says the May 11-12 wave poisoned a CI cache and minted publish credentials from inside a trusted build, so the attestation it produced was honest. Any gate that only checks for provenance would have passed it.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
A SLSA Build Level 3 attestation certifies that an artifact came out of the trusted build environment, from the claimed source, and it makes no statement about whether the code inside is what the maintainer thinks it is [10]. That distinction is the entire incident. Keyless signing draws its boundary in the same place: identity is bound to a short-lived OIDC token issued to the CI environment [12]. Once attacker code is executing inside that environment, every artifact it produces gets a signature, a certificate and a transparency log entry that are all valid, and all honestly issued [11].
The scale figures come from a Cloud Security Alliance research note, and they count different things than a quick read suggests. More than 180 compromised packages carried more than 400 malicious versions [5], which works out at roughly 2.2 bad versions per package [1], the shape of repeated republishing rather than one poisoned upload. The 518 million number is cumulative historical downloads for the affected packages [5]. For that to describe exposure, the malicious versions would have to have been fetched at something like the packages' lifetime rate during the hours they were live, and nobody has published that. The earlier wave of the same campaign hit SAP's @cap-js packages, PyTorch Lightning and Intercom in late April and early May [8].
The write-up making the provenance argument is from a team that sells the alternative, which is worth naming because it shapes the prescription [16]. Their receipt is a signed content manifest: JCS-canonical file hashes, Ed25519, anchored to the public Rekor log, optionally carrying a Zenodo DOI, verifiable offline because the public key travels in the receipt [16]. That is decent engineering. It is also, by their own account, minted inside GitHub Actions; the latest self-anchor of their own repository is Rekor index 2695953558, produced by a public CI run rather than anyone's laptop [17]. A manifest generated in a poisoned runner hashes the poisoned bytes, correctly. Honest receipts are the one thing this campaign was never short of. Content-first evidence earns its keep at comparison time, when someone already has a reason to diff release N against release N-1.
The gap that actually moves the boundary is the other one they name. If the release signing key lives outside the runner, in a KMS or behind an offline signer with a human approval step, then owning a runner no longer buys the ability to mint a valid release identity, and keyless signing has no concept of that mode [14]. The cost lands on maintainers. cosign will take your own keys, but the manifest-and-anchor layer around them is still do-it-yourself [15], and a human approval step means a person standing between a green build and a published version.
The transfer test for your own project is narrow: does a release workflow accept fork pull requests into a path that feeds the trusted build, which is the misconfiguration Akamai describes in TanStack's case [2]. Close that and this route closes. The general property does not close, because anything with execution on a release runner inherits the runner's authority to make true statements. And before content manifests get treated as the general answer, note the limit the same post concedes: a hash tells you whether two artifacts are identical, never whether one was derived from the other, so a model fine-tuned from your weights hashes differently by design [19]. That is semantic comparison, and signing does not reach it.
Ranked by verification strength, evidence, and original report placement.
According to Akamai's analysis, the May 11-12 2026 wave of the Mini Shai-Hulud campaign did not steal an npm token; it poisoned a GitHub Actions CI cache through a fork-pull-request misconfiguration in the TanStack release workflow, waited for a legitimate maintainer merge, then ran inside the trusted release pipeline.
The worm scraped credentials from the runner's memory and exchanged them for publish credentials through npm's own OIDC token endpoint.
Akamai Security Intelligence Group, May 15 2026, said the attack was "invisible and grant[ed] it SLSA attestation validation."
A Cloud Security Alliance research note counts 180+ compromised packages and 400+ malicious versions across the full campaign, affecting packages with more than 518 million cumulative historical downloads.
An earlier wave of the campaign hit SAP's @cap-js packages, PyTorch Lightning and Intercom in late April and early May.
The worm installed persistence into Claude Code session hooks and VS Code task automation, and survived an npm uninstall.
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · September 2, 2026
Follow any of these and your For You feed starts watching them — no settings page required.
build
A comment-triggered Actions workflow published ten malicious npm versions with valid provenance1 distinct publisher
security
Reading OIDC tokens out of runner memory: ChainDrop and the poisoned build1 distinct publisher
build
Shai-Hulud spreads by bumping a version number your dependency range already accepts2 distinct publishers
build
Flux moves GitOps' source of truth into registries you own, and mirroring becomes the prerequisite1 distinct publisher
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Two authorities, both secondhand
Every hard fact in this story arrives through one dev.to post. Akamai is quoted with a date and the Cloud Security Alliance with nothing but a parenthetical, and neither is linked, so a reader who wants the attack path or the 518 million-download figure at first hand cannot get there from the page. What holds up on its own terms is the reasoning about what a Build Level 3 attestation asserts -- that argument is checkable against the specification rather than against a source -- and the one Rekor index the author offers, which anyone can pull.
Wide damage, one user of the cure
Split the question and the two halves point opposite ways. The attack itself spread: two waves, named victims from SAP to PyTorch Lightning to TanStack, and a package count in the hundreds. The remedy has one disclosed deployment, and it is the remedy's own repository anchoring itself. Note also that 518 million is cumulative historical downloads of affected packages, not installs of poisoned versions -- it measures how popular the victims were, not how far the worm travelled.
A pitch that argues against itself
Riding a live incident to a product section usually inflates a story, and here the framing does run ahead of what one relayed source can carry -- particularly the assertion that the manifest-and-anchor layer is missing from the ecosystem, which only the seller of that layer states. What pulls the number back near zero is a set of concessions most vendors delete: keyless signing remains the right default, running the author's own Action with the key in a CI secret leaves you on the compromised side of the boundary, and no signature of any kind would have stopped the Claude Code persistence.
Author sells the fix, and says so
The party explaining why provenance was insufficient ships the content-manifest tool it recommends instead, mints the Rekor anchors it cites as proof, and closes with three questions its own product answers. That is a strong commercial interest in this reading of the incident. It is disclosed plainly rather than buried, and the disclosure includes the limits of the offering, which is why this sits short of the top of the scale rather than at it.
Act on the lesson, source the facts elsewhere
The structural point is safe enough to change how you think about signing gates: an attacker inside the build gets an honest attestation, and that follows from the specification, not from anyone's reporting. The specifics are a different matter. Dates, victim names and package counts all pass through a single interested narrator four months after the event, so before you cite the 180 packages or the uninstall-surviving hooks in your own incident review, go and find Akamai's and the Cloud Security Alliance's originals.