Build real security skills with AppSecEngineer—50% off sitewide with code 'NOEXCUSES50'.
.svg)
Build real security skills with AppSecEngineer—50% off sitewide with code 'NOEXCUSES50'.
On May 11, 2026, a threat group tracked as TeamPCP published 404 malicious versions across 172 npm packages and 2 PyPI packages in under six hours — a campaign researchers named Mini Shai-Hulud (Hackread; SANS ISC). High-profile targets included TanStack, Mistral AI, OpenSearch, Guardrails AI, and UiPath (The Hacker News).
That alone would be a bad week for the ecosystem. What made it a different category of incident is what the malicious packages were carrying: valid SLSA Build Level 3 provenance attestations — the first documented case of a malicious package holding a real, cryptographically verifiable SLSA L3 credential, not a spoofed one (Cloud Security Alliance).
If your organization gates dependency ingestion on SLSA attestation level — a control a lot of enterprises invested in specifically because of prior npm/PyPI compromises — that control would have said yes to these packages.
SLSA (Supply-chain Levels for Software Artifacts) is a framework, not a scanner. Build Level 3 requires that a package be built on a hardened, non-tamperable build platform — typically a hosted CI system like GitHub Actions — and that the resulting artifact carry a signed provenance statement describing which repository, commit, and workflow produced it.
That's a meaningful guarantee: it rules out a maintainer's laptop quietly producing a different binary than the one in the public repo. What it does not attest is whether the workflow run that produced the artifact was itself legitimate — authorized, triggered from a protected branch, initiated by a trusted actor. SLSA proves "this build platform produced this artifact from this workflow run." It says nothing about whether that workflow run should have happened at all. TeamPCP's campaign is the incident that made that distinction impossible to ignore.
The attack chain had three stages, and none of them required forging a signature (Cloud Security Alliance; Vectra AI):
1. Exploiting a pull_request_target misconfiguration. TeamPCP targeted a workflow misconfiguration in the TanStack open-source monorepo. pull_request_target — unlike the safer pull_request trigger — runs in the context of the base repository, with access to its secrets, even when triggered by a fork's pull request. This is a known anti-pattern (sometimes called a "Pwn Request"), but it remains common because it's the easy way to let CI comment on or label PRs from external contributors.
2. GitHub Actions cache poisoning to reach the token. Using that foothold, the worm poisoned the GitHub Actions cache to get its payload executed inside the legitimate CI runner, then extracted the runner's OIDC token directly from process memory.
3. Using the stolen OIDC token exactly as designed. Here's the part that broke the mental model most teams have of "signed = safe." The worm presented that legitimate OIDC token to Sigstore's Fulcio certificate authority — the same flow any legitimate CI job uses to obtain a short-lived signing certificate — and Fulcio issued one, because the token was real and the identity it represented was the victim repository's actual GitHub Actions identity. The resulting SLSA Build Level 3 attestation was not forged. Sigstore verified the build process correctly. The build process itself had been hijacked upstream of the point Sigstore checks.
No CVE was ever assigned to this campaign, and none is expected — there's no vulnerable code being exploited, no version to flag as "fixed in." Security tooling anchored to the CVE feed produces zero signal against this class of attack by construction (Cloud Security Alliance).
That's the second assumption this incident breaks. Most enterprise dependency-risk programs layer two controls: CVE/vulnerability scanning, and provenance/attestation checking. TeamPCP's campaign scored clean on both — no CVE to trip the scanner, and a legitimate SLSA L3 attestation to satisfy the provenance gate. The malicious payload itself (credential-stealing, worm propagation to other maintained packages) is what a runtime or behavioral control would have caught. Static, pre-install gates had nothing to work with.
It's worth being precise about what failed here, because the wrong lesson is "attestation is worthless." The right lesson is narrower: attestation answers where and how a package was built. It does not answer whether the build should have happened. Those are different questions, and enterprises that treated a SLSA L3 badge as a complete trust decision were answering only the first one.
This mirrors a pattern security teams have seen before in adjacent contexts — a code-signing certificate proves a binary wasn't tampered with in transit, not that the signing key wasn't stolen; an mTLS connection proves the channel is encrypted, not that the endpoint is trustworthy. Provenance and attestation are necessary controls. On their own, they were never sufficient.
1. Harden the workflows that produce your attestations, not just the attestations themselves. Audit every pull_request_target usage in your CI. If a workflow needs to touch secrets in response to a fork's PR, require explicit maintainer approval (workflow_run pattern or equivalent) rather than auto-triggering. This is the control that would have stopped TeamPCP's initial foothold, upstream of anything Sigstore checks.
2. Scope CI tokens and secrets to the minimum the job needs. OIDC tokens and cache access should be scoped per-job, short-lived, and least-privilege by default. Memory-scraping a token is only valuable to an attacker if that token can do something consequential — narrow what "consequential" means.
3. Treat SBOM as an input to detection, not a compliance artifact. An SBOM tells you what's in your environment. It only becomes a security control when it's paired with continuous monitoring for anomalous package behavior after install — network calls, filesystem access, credential access patterns — not just at ingestion.
4. Add runtime and behavioral verification alongside build-time attestation. Since this class of attack produces a valid attestation and no CVE, the detection signal has to come from what the package actually does post-install: unexpected outbound connections, unexpected file writes, unexpected access to CI secrets or cloud credentials. This is the layer most enterprise supply chain programs currently under-invest in relative to attestation and scanning.
5. Monitor for propagation, not just initial compromise. Mini Shai-Hulud was self-propagating — it used compromised maintainer access to poison further packages. Detecting the first compromised package fast matters less if there's no monitoring for the lateral spread across your dependency tree in the following hours.
6. Pin dependencies and stage upgrades through a quarantine window. 404 malicious versions shipped in under six hours. Organizations with dependency-update policies that require even a short delay before automatic adoption of new versions had a real, practical window to avoid ingesting the payload entirely.
7. Build this into your security architecture reviews, not just your CI configuration. CI/CD trust boundaries — who can trigger what, with which secrets, from which trigger type — are architecture decisions with security consequences. They deserve the same design-stage scrutiny as any other trust boundary in the system, reviewed before the pipeline is built, not audited only after an incident.
Attestation-plus-runtime is where the industry is heading, not attestation-plus-more-attestation. Adding a second, third, or fourth layer of build-time provenance checking doesn't address a hijacked-but-legitimate pipeline — the certificate will keep coming back valid. The gap closes with controls that observe behavior after the artifact is built and installed, which is a different tooling category (runtime detection, egress monitoring, EDR-adjacent controls extended to CI runners) than most supply chain security programs currently budget for.
This will recur across ecosystems, not just npm/PyPI. pull_request_target misconfigurations and OIDC-to-Sigstore flows aren't npm-specific; the same pattern is reproducible anywhere a build platform issues short-lived signing identities to CI jobs. Teams using SLSA or similar provenance frameworks in other language ecosystems should audit their own CI trigger configurations now rather than after their own incident.
TeamPCP's Mini Shai-Hulud campaign didn't break SLSA's cryptography or forge a signature — it hijacked the legitimate pipeline that issues real ones, and no CVE-based or attestation-only control was positioned to catch it. The lesson for engineering and security leaders isn't to abandon provenance frameworks; it's to stop treating a SLSA badge as a finished trust decision. Provenance tells you where an artifact came from. Defense-in-depth — hardened CI triggers, scoped tokens, SBOM-driven behavioral monitoring, and quarantine windows on new versions — is what tells you whether you should have trusted it.
A supply-chain security framework requirement stating a package must be built on a hardened, non-tamperable build platform (typically hosted CI like GitHub Actions), with a signed provenance statement identifying the repository, commit, and workflow that produced it. It attests how and where an artifact was built — not whether the build should have run.
On May 11, 2026, TeamPCP published 404 malicious versions across 172 npm packages and 2 PyPI packages in under six hours, hitting projects including TanStack, Mistral AI, OpenSearch, Guardrails AI, and UiPath (Hackread).
No — that's the significant part. The attestations were cryptographically valid, issued by Sigstore's Fulcio certificate authority through the normal flow. TeamPCP hijacked the legitimate build pipeline rather than faking its output.
They exploited a pull_request_target misconfiguration in the TanStack monorepo to get code running with access to repository secrets, poisoned the GitHub Actions cache to execute inside the legitimate runner, then extracted the runner's real OIDC token from process memory and presented it to Sigstore — which issued a valid certificate because the token was genuine.
A GitHub Actions misconfiguration where a workflow triggered by a fork's pull request runs in the context of the base repository, granting it access to secrets it shouldn't expose to untrusted, external code — a known anti-pattern still common because it simplifies handling external contributions.
here was no vulnerable code or version to flag — the payload came from a hijacked but technically legitimate build process. Security tooling anchored to the CVE feed produces zero signal against this class of attack by design.
172 npm packages and 2 PyPI packages, across 404 malicious versions, published within roughly a six-hour window.
No. SLSA still rules out artifact tampering after a legitimate build and remains a necessary control. This incident shows it's not sufficient on its own — it answers "where was this built," not "should this build have happened."
Runtime and behavioral monitoring on package post-install activity (unexpected network calls, file writes, credential access), hardened CI trigger configurations, scoped and short-lived CI tokens, and staged/quarantined dependency updates rather than automatic adoption of new versions.
Audit every pull_request_target usage in CI, scope OIDC tokens and secrets to least privilege, pair SBOMs with continuous behavioral monitoring rather than treating them as a compliance checkbox, and extend security architecture reviews to cover CI/CD trust boundaries, not just application code.
