Shai-Hulud was the best thing to happen to supply chain security

What it is

Aikido's data analysis of npm Trusted Publishing adoption (OIDC-based short-lived tokens, GA July 2025) against the 2025–2026 supply-chain worm wave. The reason to read past the summary is the mechanism of the latest attacks, which invert the premise that Trusted Publishing protects you.

How it works — the escalation the summary only names

Trusted Publishing replaces a stored NPM_TOKEN with a per-run token that expires in minutes: "nothing to steal." The attacks defeated this without stealing the token:

• Mini Shai-Hulud II / TanStack (May 7–11, 2026): attackers used a Pwn Request to poison the GitHub Actions cache, then waited for the legitimate release workflow to run. Because that workflow runs with id-token: write, attacker code from the poisoned cache extracted the OIDC token from runner memory and exchanged it through npm's own token endpoint. Published packages carried valid SLSA Build Level 3 provenance. Trusted Publishing wasn't bypassed — it was the attack vector.
• Miasma / Hades (June 1–7, 2026): abused the OIDC publishing endpoint directly rather than stealing tokens; later waves added a binding.gyp trick to evade install-script detection and crossed to PyPI via .pth startup execution.

flowchart TD
    A[Pwn Request via pull_request_target] --> B[Poison GitHub Actions cache]
    B --> C{Legitimate release<br/>workflow runs}
    C -->|id-token: write| D[Attacker code reads OIDC<br/>token from runner memory]
    D --> E[Exchange at npm token endpoint]
    E --> F[Publish with VALID SLSA provenance]
    G[Harden pull_request_target /<br/>scope id-token] -.cuts.-> A

Preconditions / Affected

Matters if your release pipeline runs on GitHub Actions with id-token: write and accepts pull_request_target-triggered workflows, or restores caches populated by untrusted PRs. Trusted Publishing adopters are not exempt — provenance attestation does not prove the build wasn't attacker-influenced. The earlier, simpler attacks (Debug/Chalk phishing via npmjs.help, Axios compromised-maintainer account) still apply to anyone holding long-lived tokens.

What to do

The page states no commands. Its actionable conclusion: adopting Trusted Publishing is necessary but insufficient — the real exposure is now the CI pipeline's trust boundary (Pwn Requests, cache poisoning, id-token: write scope), not token storage. Treat SLSA provenance as evidence of who built, not that the build was clean.

Caveats

Coverage remains thin: only 11,001 of the top 51,370 packages and ~25% of download volume use Trusted Publishing despite 3.4x growth. The post is a vendor (Aikido) adoption-tracking piece; the causal claim that attacks "moved the needle more than the security industry" is correlational — spikes follow named incidents but the data is weekly adoption counts, not verified attributions.