On May 11, 2026, a piece of malware did something the software industry had quietly assumed was impossible: it shipped with a valid, cryptographically signed SLSA Build Level 3 provenance attestation. The signature checked out. The provenance was genuine. The package was malicious anyway.
Stephen P. Lutar Jr., Founder & CEO, SZL Holdings · a-11-oy.com
Between May 10 and 12, 2026 — with the main publishing burst compressed into roughly five hours on May 11 — the threat group TeamPCP compromised more than 170 packages across the npm and PyPI ecosystems, publishing over 400 malicious versions spanning 19 namespaces. Affected projects had accumulated more than half a billion cumulative downloads. It is the first documented npm worm to propagate while carrying legitimately attested malicious packages.
The entry point was an orphaned CI/CD trust configuration in TanStack’s GitHub Actions
workflows — a pull_request_target workflow that retained OIDC federation despite no
longer being actively maintained. The attacker read short-lived OIDC tokens directly out of the
GitHub Actions runner’s process memory (/proc/<pid>/mem), then exchanged those
tokens with the Sigstore Fulcio certificate authority to mint legitimate signing certificates.
From there: stolen OIDC token → short-lived npm publish token → malicious versions released under
the real maintainer identity, with valid provenance describing the exact GitHub Actions job that
produced them.
The provenance was accurate. It correctly described a build that produced malware. Phase 2 of the campaign reportedly reached infrastructure at OpenAI, Grafana, and GitHub itself.
A cryptographic signature answers two questions with mathematical confidence: who signed this, and what exact bytes were signed. It answers a third question — is the signed thing safe? — not at all. The industry has spent a decade conflating the first two with the third.
| What a signature proves | What it does NOT prove | Mini Shai-Hulud reality |
|---|---|---|
| Identity of the signer (the OIDC subject) | That the signer’s environment was uncompromised | OIDC tokens stolen from runner memory; identity genuine |
| The exact bytes that were signed | That those bytes are safe to execute | Provenance accurately described a malicious build |
| That a recognized pipeline produced the artifact | That the pipeline behaved as intended | Legitimate GitHub Actions job produced malware |
SLSA and Sigstore are good. They are necessary but not sufficient. When a control becomes a checkbox — “signed: yes” — it stops being a security boundary and becomes a false sense of one.
The corollary is a posture we call behaviour-over-attestation. An attestation is a claim made at build time about the past. Behaviour is evidence gathered at runtime about the present. When the two disagree, behaviour wins. The rest of our doctrine follows from this: prove-or-downgrade (claim only what has a checkable artifact), label every value MEASURED MODELED SAMPLE, and never present an attestation as a guarantee. We do not claim a11oy is unbreakable. We claim it stops trusting the signature alone.
Below are the five mechanisms that make a11oy a structural answer to a Mini Shai-Hulud-class attack. We are explicit throughout about what is live today versus what is roadmap. The credibility comes from the honesty. Where a mechanism can be proven right now, the card binds to a real a11oy production endpoint below.
Transparency obligations for AI-generated content take effect August 2, 2026. a11oy’s C2PA content credentials and hybrid signing (4.4) are built toward exactly this — provenance of generated content, transparent and verifiable.
Supply Chain Integrity, Transparency and Trust — independent, append-only ledgers that let third parties verify receipts without trusting the producer. The direct standards answer to the self-attestation gap (4.5, roadmap).
The 2026 OMB action rescinding the prior secure-software-development self-attestation mandate in favor of a risk-based approach reflects the same realization: an attestation checkbox is not a risk control. Behaviour and replayable evidence are.
We are happy to walk through a Mini Shai-Hulud tabletop against a live a11oy instance — what the artifact-behaviour monitor would have flagged, what the 3-axis check would have rejected, and what the governance ledger would let you prove and revoke after the fact. Live signed APIs and the GAP1 behavioural monitor are available now at a-11-oy.com.