Authors: Cloud Security Alliance AI Safety Initiative
Published: 2026-05-15

Categories: Software Supply Chain Security, CI/CD Security, AI SDK Security, Threat Intelligence

Mini Shai-Hulud: When Signed Provenance Certified a Supply Chain Worm

Cloud Security Alliance AI Safety Initiative | May 2026

Key Takeaways

Between May 10 and 12, 2026, the threat group TeamPCP launched a coordinated supply chain worm — dubbed Mini Shai-Hulud — that compromised more than 170 npm and PyPI packages across 19 namespaces, publishing over 400 malicious versions [18][19] across packages that had accumulated more than 518 million cumulative historical downloads — a figure reflecting the affected packages’ total ecosystem reach rather than confirmed installs of the malicious versions during the attack window [3].
The attack’s defining escalation is that malicious package versions carried valid SLSA Build Level 3 provenance attestations issued by the Sigstore ecosystem — making this the first documented npm worm to produce legitimately attested malicious packages [3][4]. Provenance attestations verified where the packages were built, but could not verify that the build environment had been compromised.
TeamPCP achieved this by extracting short-lived OIDC tokens directly from GitHub Actions runner process memory, then exchanging those tokens with the Sigstore Fulcio certificate authority to generate legitimate signing certificates — exploiting the design assumption that a valid OIDC token represents a legitimate publisher [5][6].
The official Mistral AI SDK on PyPI was among the compromised packages, raising particular concern for organizations consuming AI services through official SDKs, as developer environments and CI pipelines installing the SDK may have had cloud credentials, API keys, and service tokens exfiltrated [1][7].
Mini Shai-Hulud extends TeamPCP’s campaign trajectory, which began in March 2026 with compromises of the Trivy security scanner, Checkmarx KICS, and LiteLLM, and now demonstrates the group’s ability to abuse identity-based publishing infrastructure at ecosystem scale [8][9].
The attack’s propagation mechanism and detection-triggered wipe capability mean that partial incident response is insufficient — any environment in the affected install window should be treated as fully compromised, since standard secret rotation procedures can trigger destructive retaliation from the persistence daemon, and attestation-based verification cannot provide confidence in package integrity when the build environment itself has been poisoned [10][11].

Background

The Shai-Hulud worm lineage — named after the giant sandworms of Frank Herbert’s Dune — represents what security researchers have described as one of the most consequential evolutions in supply chain attack methodology of the past two years [12][13]. The original Shai-Hulud worm emerged in September 2025, beginning with a compromise of the npm package rxnt-authentication and spreading autonomously to hundreds of packages by exploiting stolen CI/CD credentials to republish infected versions [12]. Shai-Hulud 2.0, identified in November 2025, extended the technique to compromise 621 unique npm packages, establishing a self-replicating attack pattern that security researchers described as the most aggressive npm supply chain campaign of 2025 [13].

The threat actor known as TeamPCP escalated in a different direction beginning in March 2026. Rather than targeting generic developer packages, the group compromised security and AI infrastructure tooling: Aqua Security’s Trivy vulnerability scanner, Checkmarx’s KICS static analysis tool, and the LiteLLM AI gateway — all tools embedded deeply in enterprise CI/CD pipelines [8][9][14]. Microsoft’s Security Blog published incident response guidance following the Trivy compromise, advising organizations to assess the potential blast radius of affected environments through threat hunting queries and to conduct thorough investigation of any pipeline that ran a Trivy scan during the affected window [15]. Palo Alto Networks Unit 42 attributed this campaign to TeamPCP based on consistent tooling patterns, infrastructure overlap, and the CanisterWorm component used across attacks [9].

Mini Shai-Hulud, the May 2026 campaign, synthesizes both lineages. It combines the self-propagating worm mechanism of the Shai-Hulud series with TeamPCP’s pattern of targeting high-value, widely trusted packages — and adds a new capability that has not been seen before in the wild: the generation of valid cryptographic provenance attestations for malicious releases. The result is a supply chain attack that exploits a documented scope boundary in provenance attestations — specifically, the gap between identity verification and build environment integrity — that the industry had not yet encountered as an active attack class in the wild.

Security Analysis

Attack Entry Point: Orphaned CI/CD Trust Configurations

The TanStack ecosystem served as TeamPCP’s primary entry point and self-propagation engine, but the root cause was not a vulnerability in TanStack’s code — it was an orphaned trust configuration in its CI/CD workflows. The attacker identified a GitHub Actions workflow file that retained OIDC federation with npm’s trusted publishing system despite no longer being actively maintained [1][5]. This misconfiguration meant that any code executing within a workflow triggered by that repository’s Actions environment could legitimately mint short-lived npm publish tokens by presenting a valid OIDC token to npm’s authorization endpoint.

The initial exploitation followed a three-step sequence. First, the attacker created a fork of the TanStack/router repository and opened a pull request designed to trigger a pull_request_target workflow — a GitHub Actions event type that runs with the privileges of the target repository rather than the submitting fork, and which executes whatever code the workflow is configured to check out [1][3]. Second, the attacker’s code poisoned the shared GitHub Actions pnpm cache with a malicious store, seeding future workflow runs with attacker-controlled binaries. Third, when legitimate maintainer pull requests were subsequently merged and the release workflow ran, it restored the poisoned cache; attacker-controlled binaries then extracted OIDC tokens directly from the GitHub Actions runner’s process memory by reading /proc/<pid>/mem [5][6].

The critical consequence was that the attacker never needed to steal npm credentials through conventional means. The entire publish chain operated through identity federation: stolen OIDC token, exchanged for a short-lived npm publish token, used to release malicious versions under the legitimate maintainer identity [1][10]. From npm’s perspective, the release was indistinguishable from a legitimate maintainer action.

The Sigstore Attestation Problem

The element with the broadest implications for software supply chain security posture — and the most novel aspect of Mini Shai-Hulud — is the attestation question. When the compromised TanStack releases were published, they carried valid SLSA Build Level 3 provenance attestations signed by the Sigstore ecosystem [3][4]. These attestations are not forgeries. They are accurate records of what Sigstore could verify: that the packages were published from a GitHub Actions run operating under the TanStack repository’s identity.

What the attestations cannot record is the condition of that build environment. Sigstore’s Fulcio certificate authority issues signing certificates based on OIDC token verification — it confirms who is presenting the token, not whether the code running in that identity’s environment is what the maintainer intended to run [16][17]. The SLSA threat model addresses tampering with build outputs and provenance records, but it does not address the scenario where attacker-controlled code executes within a legitimate, properly attested build job and produces a malicious artifact that the provenance system then correctly and accurately describes as having originated from that job [4][16].

Vectra AI’s research on the Sigstore trust gap articulates the distinction clearly: a valid attestation confirms that a package was built in a specific pipeline under a specific identity; it cannot confirm that the pipeline evaluated code the maintainer wrote [6]. An organization verifying attestations on TanStack packages from May 11, 2026, would have confirmed the packages were built in TanStack’s GitHub Actions environment — which is true — without detecting that the build environment had been compromised. This is not a failure of Sigstore’s implementation; it is a boundary condition of what identity-based attestations are designed to guarantee, now being exploited in the wild for the first time.

Malware Capabilities and Exfiltration

Each compromised package version contained a preinstall hook that served as the initial payload loader. At install time, the hook downloaded the Bun JavaScript runtime — an ostensibly legitimate tool — as a living-off-the-land binary, then launched a 2.3 MB obfuscated JavaScript implant named router_init.js [1][2]. The obfuscated single-line file implements a multi-stage credential harvesting capability targeting a broad range of secrets present in developer environments and CI/CD pipelines, including CI secrets and build tokens, cloud provider credentials and IAM keys, Kubernetes service account tokens, HashiCorp Vault secrets, SSH private keys, and cryptocurrency wallet data [1][10].

Two design choices make detection and response unusually difficult. First, the worm installs a persistence daemon named gh-token-monitor that polls at approximately 60-second intervals to verify that stolen tokens remain valid. If the monitoring logic detects that credentials have been revoked — indicating that the victim organization is aware of the compromise and rotating secrets — the daemon immediately executes a destructive wipe of the victim’s home directory [3]. This detection-triggered wipe mechanism effectively penalizes rapid incident response and creates pressure against standard remediation procedures. Second, exfiltration does not use HTTP-based command-and-control infrastructure that network monitoring tools typically flag; instead, stolen credentials are transmitted through the Session peer-to-peer messaging network, whose encrypted protocol is difficult to distinguish from legitimate messaging traffic using standard network inspection tools, though protocol fingerprinting may still detect it in hardened environments [5][10].

Scale and Ecosystem Impact

The campaign’s scope was broad enough to constitute an ecosystem-level event. The campaign ran from May 10 through May 12, with the primary publishing burst occurring in approximately five hours on May 11 — during which TeamPCP published over 400 malicious versions spanning 172 distinct packages across 19 namespaces [1][2][5][18][19]. The major affected packages illustrate both the breadth and the strategic targeting of the campaign.

Namespace / Package	Ecosystem	Approximate Weekly Downloads	Notes
@tanstack/* (42 packages)	npm	Millions collectively	Core front-end data libraries
UiPath (65 packages)	npm	—	RPA/automation tooling
Mistral AI SDK	PyPI	—	Official AI provider SDK [7]
OpenSearch JS client	npm	~1.3M/week (npm registry)	AWS-maintained [2]
Guardrails AI	PyPI	—	AI safety tooling [1]
Squawk (12+ packages)	npm	—	SQL linting tooling

The Mistral AI SDK compromise warrants particular attention for AI-focused security teams. Organizations using the official mistralai Python package in automated workflows may have exposed API keys providing access to commercial AI inference services, alongside any cloud credentials and CI tokens present in those environments. The intersection of AI SDK supply chain compromise with credential exfiltration creates a compounding risk: stolen AI API keys can be monetized directly or used to run model queries at the victim’s expense, while stolen cloud credentials may provide lateral movement pathways into cloud environments that also host AI workloads and training infrastructure.

Recommendations

Immediate Actions

Any environment — developer workstation, CI runner, or deployment pipeline — that installed a package from an affected namespace during May 10–12, 2026, should be treated as fully compromised regardless of whether attestation validation passed. Credential rotation should proceed in the following priority sequence: npm publish tokens and registry credentials first, then GitHub personal access tokens and Actions secrets, then cloud provider IAM credentials, then any Vault or secrets-manager tokens, and finally SSH keys [10][11]. Rotation should be performed from a known-clean environment, not from the system suspected of compromise, because the detection-triggered wipe mechanism may execute a destructive action if rotation is detected from the compromised host.

Organizations should audit all GitHub Actions workflow files for pull_request_target triggers that check out external code or restore caches without explicit content verification. Any workflow with id-token: write permissions — the OIDC capability that enables trusted publishing — should be reviewed to confirm that only currently maintained, actively audited workflows retain this permission. Orphaned workflow files from former maintainers or deprecated release pipelines represent the class of misconfiguration TeamPCP exploited here [1][3].

Short-Term Mitigations

Three layered controls address the attack patterns demonstrated by Mini Shai-Hulud. First, running npm ci --ignore-scripts in CI environments prevents preinstall and postinstall hooks from executing at install time, specifically defeating the class of attack where the malware activates during package installation [10][11]. This configuration may break packages that rely on install-time scripts for legitimate purposes; organizations should test against their dependency graph before applying this setting broadly [10][11]. Second, adopting exact version pinning — replacing ^ and ~ range specifiers with exact version numbers in package manifests, and committing verified lockfiles — prevents the worm’s self-propagation from silently introducing malicious versions into projects that accept patch or minor version ranges [11]. Third, routing package installs through a private registry mirror configured with a 24-to-48-hour delay for newly published versions provides a potential buffer window during which early-detection services may identify malicious packages before they reach internal consumers [10][11]. Organizations should verify that their chosen detection service had adequate coverage during the Mini Shai-Hulud incident window before depending on this control, since malicious packages were flagged and removed within hours of publication.

Provenance verification should be understood as a necessary but insufficient control after this incident. Attestation verification confirms build identity and build environment type; it does not confirm that the code executed in that environment was safe. Organizations should combine provenance checks with behavioral analysis at install time and cross-reference against ecosystem threat intelligence feeds that flag suspicious packages based on behavioral signatures rather than identity metadata alone.

Strategic Considerations

Mini Shai-Hulud exposes a category-level gap in the supply chain security assurance model that the industry has been building toward. The assumption underlying SLSA Level 3 adoption is that a higher-trust build environment reduces the probability that malicious packages carry valid attestations. TeamPCP’s technique demonstrates that if an attacker can execute code within a legitimate build environment — through cache poisoning, dependency confusion, or workflow misconfiguration — SLSA Level 3 attestations become a trust signal the attacker can generate on demand.

This does not invalidate provenance attestations as a control; it redefines their threat model coverage. Attestations effectively prevent a class of attacks where an adversary substitutes a completely unrelated package or modifies a release artifact after the fact. They do not address scenarios where the build environment itself is compromised. Organizations should model their supply chain assurance around layered defense: attestations for post-build tampering detection, combined with pre-build controls that prevent attacker code from entering the build environment in the first place. Ephemeral, isolated build environments with no shared caches between pull request workflows and release workflows would have prevented the specific cache-poisoning step TeamPCP exploited here [1][5].

The pull_request_target workflow class deserves specific policy attention. GitHub’s documentation notes that this event type runs with the permissions of the base repository even when triggered by a forked PR — a design choice that enables external contributors to trigger workflows that need repository secrets, but which creates a privilege escalation pathway when the workflow’s job steps check out and execute the contributor’s code. Security teams should audit all pull_request_target workflows and apply explicit code checkout controls that prevent execution of forked content in privileged workflow contexts.

CSA Resource Alignment

Mini Shai-Hulud maps directly to multiple layers of CSA’s AI and cloud security frameworks, reflecting the compound nature of an attack that spans CI/CD infrastructure, identity federation, software supply chains, and AI tooling.

CSA’s AI Controls Matrix (AICM) — a superset of the Cloud Controls Matrix designed for AI-specific deployments — addresses supply chain integrity requirements for AI model delivery and SDK distribution. The Mistral AI SDK compromise illustrates how AI supply chain risk extends beyond model weights and training data to encompass the Python and npm packages that organizations use to integrate AI capabilities into their applications. AICM supply chain controls should be applied to AI SDK dependencies with the same rigor applied to core infrastructure libraries.

The MAESTRO threat modeling framework for agentic AI systems identifies software supply chain attacks as a primary threat vector against agentic pipelines, which often install packages from npm and PyPI as part of tool and plugin ecosystems. An agentic AI environment that installed Guardrails AI — a package specifically designed to enforce AI safety guardrails — from PyPI during the Mini Shai-Hulud window would have had its safety tooling turned into a credential exfiltration agent. This scenario illustrates MAESTRO’s concern that agentic systems face compound supply chain risk because their functionality depends on a broad and rapidly evolving set of external dependencies.

CSA’s DevSecOps guidance — including the Six Pillars of DevSecOps: Automation — directly addresses the CI/CD pipeline security hygiene that Mini Shai-Hulud exploited. Specific controls mapped to this incident include: secrets scanning in workflow definitions to detect OIDC scopes that should have been revoked, workflow permission auditing, cache isolation between privileged and unprivileged workflow contexts, and supply chain verification gates. Organizations implementing CSA’s DevSecOps automation pillar should review these controls in light of the pull_request_target attack class.

The CSA STAR (Security Trust Assurance and Risk) program’s supply chain assessment criteria offer a vendor assurance mechanism relevant to organizations evaluating AI SDK providers. Package publishers with STAR assessments that document CI/CD pipeline security controls and workflow permission policies may offer a higher baseline of assurance than unassessed publishers — though the value of such attestations depends on the scope and rigor of the assessment criteria applied to software distribution pipelines specifically. The Mistral AI case highlights the value of extending STAR-equivalent assurance to AI SDK distribution pipelines.

Finally, CSA’s Zero Trust Architecture guidance is directly applicable to the credential exposure risk created by Mini Shai-Hulud. A Zero Trust posture that treats all credentials as potentially compromised after any unverified package install — and implements continuous verification rather than assuming trust based on prior authentication — provides a resilience layer that limits the downstream impact of credential theft, regardless of how that theft occurred. Zero Trust credential issuance practices, including short-lived tokens, scoped permissions, and just-in-time access, reduce the dwell time value of any credentials the worm successfully exfiltrated.