Mini Shai-Hulud: Frequently asked questions about the TeamPCP npm and PyPI supply chain campaign
A self-propagating worm has compromised more than 170 npm and PyPI packages, defeating provenance at 2026-5-21 15:28:22 Author: www.tenable.com(查看原文) 阅读量:6 收藏

A self-propagating worm has compromised more than 170 npm and PyPI packages, defeating provenance attestation and breaching OpenAI and Mistral AI. Here is what you need to know.

Key takeaways

  1. Mini Shai-Hulud is a self-propagating worm by TeamPCP that steals developer and cloud credentials across the npm and PyPI ecosystems.
  2. The campaign achieved a critical security first by compromising packages with valid SLSA Build Level 3 provenance attestations, proving that process integrity controls can be defeated.
  3. Any system that installed a compromised package must be treated as fully compromised.

Background

Between September 2025 and May 2026, a threat group tracked as TeamPCP has conducted a series of coordinated supply chain attacks across the npm and PyPI package ecosystems. The campaign, which the group calls Shai-Hulud, uses a self-propagating worm that steals developer and cloud credentials, then leverages those credentials to publish poisoned versions of additional packages. Each compromised continuous integration and continuous deployment (CI/CD) pipeline becomes a new distribution vector, enabling exponential spread. The current iteration is known as Mini Shai-Hulud.

Tenable’s Research Special Operations Team (RSO) has compiled this FAQ to discuss what Mini Shai-Hulud is, how the campaign operates, who has been affected and what organizations should do to protect their software supply chains.

FAQ

What is Mini Shai-Hulud?

Mini Shai-Hulud is a multi-wave supply chain attack campaign that targets the npm and PyPI open-source package registries. The name, chosen by the threat group TeamPCP, is a reference to the sandworms in Frank Herbert's "Dune" novels, and the campaign carries a consistent Dune-universe theme throughout its infrastructure (dead-drop repository branch names, marker strings and operational messaging all draw from the Dune lexicon).

What is the difference between Shai-Hulud and Mini Shai-Hulud?

Shai-Hulud is the worm family. Mini Shai-Hulud is the current generation of that worm and the name TeamPCP uses for the active campaign.

When did these campaigns start?

The original Shai-Hulud worm appeared in September 2025 as the first self-replicating malware observed in the npm ecosystem. It could steal maintainer tokens and use them to publish poisoned versions of other packages without further attacker input.

A second generation, sometimes called SHA1-Hulud, surfaced in November 2025 with updated wiper functionality and improved credential harvesting.

A third variant designated SANDWORM_MODE, introduced adaptive targeting that allowed the worm to enumerate CI/CD pipeline structures before deciding how to propagate. Each generation directly addressed detection and takedown techniques applied to its predecessor, suggesting the operators monitored defensive responses and adapted accordingly.

Mini Shai-Hulud is the fourth generation, active since late April 2026. The "Mini" is TeamPCP's own ironic branding; in practice, this variant is far more destructive than the original. Its distinguishing capabilities include:

  • SLSA Build Level 3 provenance attestation forgery (allowing malicious packages to pass cryptographic verification)
  • OIDC token extraction directly from GitHub Actions runner process memory
  • Persistence hooks targeting AI coding agents and developer IDEs
  • Cross-ecosystem propagation spanning both npm and PyPI,
  • Triple-redundant credential exfiltration through a dedicated command-and-control server
IterationNameFirst Observation
FirstShai-HuludSeptember 2025
SecondSHA1-HuludNovember 2025
ThirdSANDWORM_MODEMarch 2026
FourthMini Shai-HuludApril 2026

What are the vulnerabilities associated with Mini Shai-Hulud?

The TanStack compromise has been assigned a single CVE:

CVEDescriptionCVSSv3VPR
CVE-2026-45321Malicious code injection in 42 @tanstack packages via three chained GitHub Actions9.69.2

*Please note: Tenable’s Vulnerability Priority Rating (VPR) scores are calculated nightly. This blog post was published on May 21, 2026 and reflects VPR at that time.

What is CVE-2026-45321

CVE-2026-45321 describes a chained exploitation of three weaknesses in TanStack's GitHub Actions CI/CD configuration. The attacker created a fork of the TanStack/router repository under a renamed account to avoid detection, then opened a pull request that triggered a pull_request_target workflow. This workflow executed code from the attacker's fork in the base repository's trusted context, allowing the attacker to poison the GitHub Actions cache with malicious binaries. When legitimate maintainer pull requests were later merged, the release workflow restored the poisoned cache. Attacker-controlled code then extracted OpenID Connect (OIDC) tokens directly from the runner's process memory and exchanged them with npm's federation endpoint for full publish credentials.

The result was 84 malicious package versions published across 42 TanStack packages in under six minutes, all carrying valid SLSA Build Level 3 provenance attestations from Sigstore.

Are there other CVEs associated with Mini Shai-Hulud?

At present, only CVE-2026-45321 has been assigned. It applies specifically to the TanStack wave of the campaign. The broader Mini Shai-Hulud campaign exploits CI/CD trust relationships and stolen credentials rather than traditional software vulnerabilities.

Which threat actors are behind this campaign?

Multiple independent security firms attribute the campaign to TeamPCP, a financially motivated cybercriminal group that emerged in late 2025. Google's Threat Intelligence Group tracks the group as UNC6780. Other tracked aliases include DeadCatx3, PCPcat, ShellForce, and CipherForce, according to Snyk and Palo Alto Networks Unit 42.

TeamPCP is assessed as responsible for several prior high-profile supply chain compromises, including the Aqua Security Trivy scanner compromise (March 2026), the Bitwarden CLI npm compromise (April 2026), the Checkmarx Jenkins AST Plugin backdoor (May 2026) and GitHub (May 2026). Unit 42 has documented TeamPCP's announced partnership with the Vect ransomware group, suggesting the credential harvesting pipeline may serve as an initial access pathway for ransomware deployment.

What organizations have been affected?

At least four organizations have publicly confirmed breaches linked to the campaign:

  • OpenAI disclosed on May 15 that two employee devices in its corporate environment were compromised after ingesting a malicious TanStack package. Limited credential material was exfiltrated from internal source code repositories, including code-signing certificates for macOS, Windows, iOS, and Android applications. OpenAI is rotating those certificates and requiring all macOS users to update their applications before June 12, 2026. The company stated it found no evidence that customer data, production systems, or intellectual property were compromised.
  • Mistral AI confirmed that a codebase management system was compromised and SDK packages were contaminated. Non-core code repositories were accessed. On May 17, a TeamPCP-linked forum account claimed to be selling alleged Mistral AI repositories.
  • The European Commission (europa.eu) was reportedly affected by the earlier Trivy wave in March 2026, with over 90 gigabytes of data exfiltrated according to ReversingLabs reporting.
  • GitHub disclosed on May 19 that they were investigating claims made by TeamPCP after the group posted GitHub source code for sale. Shortly after, they confirmed that roughly 3,800 internal repositories were breached. The root cause was a trojanized Visual Studio Code extension that had been installed by an employee. That extension was later revealed to be Nx Console, in which a malicious copy of the extension was available for around 18 minutes on the Visual Studio Marketplace. According to the Nx Console security advisory, the root cause was a developer's account that had been compromised via theTanstack supply-chain compromise. The leaked credentials were then abused to run workflows on the Nx Console GitHub repository.

Beyond named victims, the campaign has compromised over 170 packages spanning both npm and PyPI with more than 518 million cumulative weekly downloads. OX Security data shows that at least 400 GitHub repositories of stolen credentials were created as part of the campaign.

How does the worm spread?

The campaign's core mechanism is a self-propagating worm. When a developer or CI/CD runner installs a compromised package, the malware executes during installation and harvests credentials stored on the system, including npm tokens, GitHub personal access tokens, AWS credentials, Kubernetes secrets, SSH keys and HashiCorp Vault tokens. The worm then uses those harvested credentials to publish poisoned versions of other packages the victim has access to, creating a chain reaction that spreads across the ecosystem without requiring further action from the attacker.

Mini Shai-Hulud employs three distinct attack chains depending on the access conditions available:

  • Token theft and automated mass-publish is the most common method. The attacker compromises an npm maintainer account or token through prior credential harvesting, then runs an automated script that publishes trojanized versions of every package accessible to the compromised account. The trojanized packages include a preinstall hook that downloads the Bun JavaScript runtime and executes a large, obfuscated credential-stealing payload before the dependency installation completes.
  • OIDC hijack with provenance defeat was used in the TanStack wave and represents the most technically sophisticated variant. Instead of stealing a stored credential, the attacker extracted a short-lived OIDC token from the runner's process memory, allowing publication through the project's own trusted pipeline with valid cryptographic attestation.
  • PyPI injection targets Python packages through compromised maintainer accounts. A dropper injected into the package's initialization file downloads a separate malicious payload from attacker-controlled infrastructure.

All three chains converge on the same post-exploitation behavior: credentials are exfiltrated through three redundant channels (a dedicated command-and-control server, the decentralized Session messenger network and GitHub API dead drops), and the harvested tokens are used to propagate the worm to additional packages.

Why is the SLSA provenance defeat significant?

SLSA (Supply-chain Levels for Software Artifacts) is a framework for verifying that software was built from a trusted source through a trusted process. Build Level 3, the highest practical level, requires cryptographic provenance generated by the build system itself, verified through Sigstore. Running npm audit signatures on a Level 3-attested package should confirm that the package was built exactly as the maintainer intended.

The Mini Shai-Hulud TanStack wave demonstrated that provenance attestation can verify that the build pipeline is legitimate without verifying that the code being built is safe. Because the attacker hijacked the legitimate pipeline itself (rather than publishing from an unauthorized account), the resulting packages carried valid attestations. Organizations that relied on provenance verification as a primary supply chain security control were unable to detect the compromise.

This finding has implications beyond this specific campaign. Any security control that verifies process integrity without independently verifying code integrity is vulnerable to the same class of attack. Provenance remains valuable but is no longer sufficient as a standalone trust signal for open-source packages. When malicious code can bypass cryptographic build verification, code scanning cannot live in a vacuum; it must be continuously validated alongside identity entitlements and runtime posture.

What about the open-sourced code and copycat attacks?

On May 12, 2026, TeamPCP published the Shai-Hulud worm source code on GitHub under an MIT License with the message: "Shai-Hulud: Open Sourcing The Carnage." The release included operational guidance encouraging users to customize encryption keys and infrastructure for their own campaigns. TeamPCP simultaneously announced a $1,000 contest on BreachForums for the largest supply chain attack using the code.

OX Security detected four malicious npm packages from separate threat actors deploying Shai-Hulud clones in May 2026, including chalk-tempalte (a typosquat of the popular Chalk library), @deadcode09284814/axios-util, axois-utils, and color-style-utils. These copycat packages use the open-sourced worm code with modified command-and-control infrastructure and credential exfiltration targets.

A rival worm called PCPJack has also been observed actively evicting TeamPCP infections while stealing credentials independently, adding further complexity to the threat landscape.

Is CVE-2026-45321 in the CISA Known Exploited Vulnerabilities (KEV) catalog?

As of May 20, 2026, CVE-2026-45321 is not listed in the CISA KEV catalog. NHS England issued a security alert related to the campaign, but no public advisory from CISA has been published.

What should organizations do?

  1. Scan your dependency trees immediately. Check lockfiles and CI logs for any affected package versions across the @tanstack, @uipath, @mistralai, @opensearch-project, @antv, and @squawk namespaces. Community-maintained detection scripts can assist, though organizations should verify third-party scanning tools before deployment.
  2. Check for persistence before revoking tokens. The worm installs a gh-token-monitor daemon (via systemd on Linux or launchctl on macOS) that polls GitHub every 60 seconds and triggers a recursive file deletion if it detects that the token has been revoked. Search for and remove this daemon, as well as injected tasks in.vscode/tasks.json and Claude Code hooks in ~/.claude/settings.json, before rotating credentials.
  3. Rotate all credentials on potentially affected systems. If exposure is suspected, rotate GitHub tokens, npm tokens, AWS credentials, HashiCorp Vault tokens, Kubernetes service accounts, Docker credentials, and CI/CD secrets. Treat any system that installed a compromised package version as fully compromised.
  4. Harden CI/CD pipeline configurations. Replace pull_request_target workflows with pull_request for any workflow that executes code from pull requests. Pin all GitHub Actions and workflow steps to immutable commit SHAs rather than tags or branches. Implement cache isolation between fork-originated and maintainer-originated workflows. Restrict secret access to named workflow steps using the GitHub Actions permissions key.
  5. Implement structural dependency controls. Deploy --ignore-scripts as the default for npm installs with explicit allowlisting for trusted lifecycle hooks. Pin all dependencies to exact versions and enforce lockfile integrity verification in CI. Consider implementing minimumReleaseAge policies to delay automatic installation of newly published versions.
  6. Audit for credential storage on developer machines. The payload targets more than 80 environment variables and filesystem paths, including.aws/credentials, .npmrc, .ssh/ directories, .kube/config, and .docker/config.json. Transition from long-lived filesystem credentials to short-lived tokens and ephemeral CI/CD environments wherever possible.
  7. Monitor for campaign indicators. Watch for network connections to 83.142.209[.]194, DNS queries to getsession[.]org endpoints from CI runners, and GitHub repository creation matching Dune-themed naming patterns. Organizations with Software Composition Analysis tools should ensure their rulesets include the campaign's known payload hashes and behavioral indicators.

Has Tenable released any product coverage for these vulnerabilities?

Yes, Tenable customers can use Tenable One Exposure Management Platform to assess their exposure surface related to Mini Shai-Hulud. Tenable One provides visibility into software dependencies and CI/CD pipeline configurations, enabling organizations to identify potentially compromised packages within their environments and prioritize remediation based on their specific exposure context.

Tenable One Cloud Exposure Management provides immediate inventory and prioritization coverage across five dimensions:

  • Continuous package inventory across every cloud workload allowing you to scan container images, VMs, and registry artifacts to maintain a live software bill of materials (SBOM). The moment indicators of compromise (IOCs) publish, Tenable identifies every asset pulling the compromised versions.
  • Reachability and exploitability context. This is where Tenable One Cloud Exposure Management separates from list-based software composition analysis (SCA), determining whether the compromised package is actually loaded at runtime, whether the workload is internet-exposed and whether the malicious code path executes on import.
  • Pipeline-to-cloud lineage. Tenable One Cloud Exposure Management traces compromised packages back through CI/CD to the build artifacts they produced, through runtime. Tenable also provides runtime reachability analysis with eBPF scanning and AI-powered Threat Stories, adding yet another actionable layer of threat discovery and response.
  • Asset-criticality prioritization. Tenable ranks findings by business context, identity blast radius via cloud infrastructure entitlement management (CIEM), and data sensitivity via data security posture management (DSPM) so response teams work the highest-risk assets first.
  • Unified findings inside Tenable One. SCA hits don’t sit in isolation. They land alongside CSPM misconfigurations, identity exposures, and runtime signals from CDR, correlated by Hexa AI into a single prioritized exposure. The SCA finding joins to the IAM role that pipeline assumes, the secrets it can access and the data those secrets unlock.

Additionally, a list of Tenable plugins for CVE-2026-45321 can be found on the individual CVE page as they’re released. Coverage for the original Shai-Hulud variants can be found in plugin ID 265897.

These links will display all available plugins for these vulnerabilities, including upcoming plugins in our Plugins Pipeline.

Get more information

Join Tenable's Research Special Operations (RSO) Team on Tenable Connect for further discussions on the latest cyber threats.

Learn more about Tenable One, the Exposure Management Platform for the modern attack surface.


文章来源: https://www.tenable.com/blog/mini-shai-hulud-frequently-asked-questions
如有侵权请联系:admin#unsafe.sh