If you work anywhere near open-source infrastructure, CI/CD pipelines, or cloud-native tooling, you need to know about the Mini Shai-Hulud worm. Named after the colossal sandworms of Frank Herbert’s Dune, this self-propagating malware—deployed by the threat actor group TeamPCP—burrowed through the npm and PyPI ecosystems in May 2026, compromising hundreds of packages and turning trusted developer tooling into a weapon.

This is not a theoretical supply chain risk. This is one of the most sophisticated attacks the open-source ecosystem has ever faced.

Who is TeamPCP?

TeamPCP (also tracked under aliases PCPcat, ShellForce, DeadCatx3, and CipherForce) is a financially motivated cybercriminal group first observed in late 2025. Early reports suggest a loose-knit collective of young individuals, though their geographic origin remains unconfirmed.

Timeline of Activity

Period Activity
Nov–Dec 2025 Initial operations targeting exposed Docker APIs, Kubernetes control planes, Ray dashboards, and Redis services. Deployed XMRig for Monero mining on compromised infrastructure.
Early 2026 Shifted to developer tool poisoning. Compromised security scanners like Aqua Security’s Trivy and Checkmarx KICS, as well as the AI proxy tool LiteLLM on PyPI.
May 2026 Launched the Mini Shai-Hulud worm campaign, poisoning 170+ npm packages and multiple PyPI packages in a single coordinated attack.

Their monetization model is multifaceted: credential theft, ransomware partnerships (notably with a group called Vect), cryptomining, and selling compromised access on underground markets.

What is the Mini Shai-Hulud Worm?

The Mini Shai-Hulud is a self-propagating supply chain worm. Unlike a typical malicious package that compromises a single dependency, this worm is designed to spread autonomously—harvesting developer credentials, using them to publish infected versions of other packages the victim maintains, and repeating the cycle indefinitely.

Think of it as a chain reaction: one compromised package infects the maintainer’s environment, steals their publishing tokens, and then weaponizes every other package they have access to.

Affected Targets

The May 2026 campaign hit an alarming number of high-profile projects:

  • TanStack (TanStack Query, TanStack Router, etc.)
  • Mistral AI
  • UiPath
  • OpenSearch
  • Guardrails AI
  • Telnyx
  • And hundreds more across npm and PyPI

The Attack Chain: How It Works

The sophistication of this attack lies in its multi-stage exploit chain that abuses trust at every layer of the modern software development lifecycle.

Stage 1: Initial Access via CI/CD Pipeline Poisoning

The attackers exploited a chain of three GitHub Actions vulnerabilities to gain initial access:

  1. pull_request_target Trigger Abuse — The attackers submitted pull requests from forked repositories. Workflows configured with the pull_request_target trigger execute in the target repository’s context, giving the attacker’s code access to the repo’s secrets and CI/CD environment.

  2. GitHub Actions Cache Poisoning — Through the above execution context, the attackers injected malicious artifacts into the project’s shared GitHub Actions build cache. This payload would lay dormant until the next legitimate build.

  3. OIDC Token Extraction — When a legitimate maintainer triggered a release workflow (e.g., merging to main), the CI system restored the poisoned cache. The malicious code running inside the trusted pipeline then:

    • Read the ACTIONS_ID_TOKEN_REQUEST_TOKEN from runner process memory
    • Used it to request a legitimate OIDC token from GitHub
    • Presented this token to Sigstore’s Fulcio CA to mint a valid signing certificate
    • Published the compromised package with valid SLSA Build Level 3 provenance attestations

Stage 2: Credential Harvesting

Once executing inside a developer’s environment or CI runner, the worm aggressively harvests secrets:

  • GitHub Personal Access Tokens (PATs) and npm/PyPI publishing tokens
  • AWS IAM credentials (via environment variables and the metadata service)
  • GCP/Azure cloud credentials
  • Kubernetes service account tokens and kubeconfig files
  • HashiCorp Vault secrets
  • SSH keys

Stage 3: Autonomous Propagation

With stolen credentials in hand, the worm:

  1. Enumerates all packages the compromised developer has publish access to
  2. Injects the malicious payload into each package
  3. Publishes new, infected versions using the hijacked tokens
  4. The cycle repeats with every new victim

In Python packages, the payload was typically injected via __init__.py modification. In npm, it executed during the install lifecycle hook or upon package import. Some variants fetched remote payloads (like transformers.pyz) from attacker-controlled domains such as git-tanstack.com.

Why SLSA Provenance Failed

This is arguably the most alarming aspect of the attack. The compromised packages carried valid, cryptographically signed SLSA Build Level 3 provenance attestations—the gold standard for supply chain integrity verification.

The Critical Distinction

SLSA provenance proves where and how an artifact was built. It does not verify that the code running inside the build pipeline is safe or authorized.

Because the attacker-controlled payload executed within the legitimate CI/CD workflow (via cache poisoning), the resulting attestation was technically accurate:

“Yes, this package was built by the repository’s authorized build system.”

The attestation was telling the truth. The build system was legitimate. The code inside it was not.

The Takeaway

Provenance verification is necessary but not sufficient. It must be layered with:

  • Runtime behavioral analysis during build
  • Source code integrity verification before build
  • CI/CD pipeline hardening (especially around pull_request_target and cache isolation)

Persistence: Surviving Uninstallation

One of the most insidious aspects of Mini Shai-Hulud is its persistence strategy. The worm doesn’t just steal credentials—it embeds itself deep into developer environments so that uninstalling the malicious package is not enough to remediate.

AI Coding Agent Hooks

The worm injects malicious hooks into .claude/settings.json, leveraging SessionStart triggers. Every time a developer starts a new AI coding session (e.g., with Claude Code), the payload re-executes automatically.

VS Code Task Injection

It modifies .vscode/tasks.json to include folderOpen auto-run triggers. Simply opening the project directory in VS Code re-infects the environment.

Persistent Daemons

On macOS, the worm installs a LaunchAgent (e.g., gh-token-monitor). On Linux, it creates a systemd user service. These daemons monitor for credential revocation—and if they detect that stolen tokens have been rotated, they trigger a destructive wipe handler that attempts to delete files in the user’s home directory.

Why This Matters

These persistence vectors target directories (.vscode/, .claude/) that are:

  • Rarely audited
  • Often excluded from version control via .gitignore
  • Implicitly trusted by developers

The worm effectively transforms trusted development tools into persistent execution vectors.

Stealthy Exfiltration via Session Messenger

Traditional malware exfiltrates data to a centralized C2 server—a domain or IP address that defenders can blocklist. Mini Shai-Hulud takes a different approach.

Stolen credentials are routed through the Session decentralized P2P messenger network, using endpoints like filev2.getsession.org. This traffic is:

  • End-to-end encrypted via onion routing
  • Indistinguishable from legitimate encrypted messaging app traffic
  • Impossible to block via traditional IP/domain-based firewall rules

Standard network security controls are effectively blind to this exfiltration channel.

Indicators of Compromise (IOCs)

If you suspect your environment may have been impacted, check for the following:

Filesystem Artifacts

# Check for malicious AI agent hooks
find . -path '*/.claude/settings.json' -exec grep -l 'SessionStart' {} \;

# Check for VS Code task injection
find . -path '*/.vscode/tasks.json' -exec grep -l 'folderOpen' {} \;

# Check for persistent daemons (macOS)
ls ~/Library/LaunchAgents/ | grep -i 'gh-token-monitor'

# Check for persistent daemons (Linux)
systemctl --user list-units | grep -i 'gh-token-monitor'

Suspicious Domains

  • git-tanstack.com (attacker-controlled payload server)
  • Any unexpected outbound connections to filev2.getsession.org

Package Audit

# Check for recently updated dependencies with unexpected versions
npm audit
pip audit

# Review recent package publications under your account
npm whoami && npm profile get

Immediate Remediation Steps

If you’ve installed any affected packages or suspect compromise:

1. Rotate Everything

Immediately rotate all credentials accessible from the affected environment:

  • GitHub PATs and deploy keys
  • npm/PyPI publishing tokens
  • AWS/GCP/Azure access keys
  • SSH keys
  • Kubernetes service account tokens
  • HashiCorp Vault tokens
  • Database credentials

2. Purge Persistence

# Remove malicious LaunchAgents (macOS)
launchctl unload ~/Library/LaunchAgents/gh-token-monitor.plist
rm ~/Library/LaunchAgents/gh-token-monitor.plist

# Remove malicious systemd services (Linux)
systemctl --user stop gh-token-monitor
systemctl --user disable gh-token-monitor
rm ~/.config/systemd/user/gh-token-monitor.service

# Clean IDE configurations
rm -rf .vscode/tasks.json  # Review before deleting if you have legitimate tasks
rm -rf .claude/settings.json

3. Rebuild from Clean State

Treat all impacted systems—CI/CD runners, developer machines, build environments—as fully compromised. Rebuild from known-clean snapshots or images.

4. Audit Package Publications

Review your npm and PyPI accounts for any packages published without your knowledge:

# Check npm publish history
npm access ls-packages

# Check PyPI releases
pip index versions <your-package>

Lessons for the Industry

The Mini Shai-Hulud campaign exposes fundamental assumptions that the industry has been operating under:

1. Provenance ≠ Safety

SLSA provenance attestations verify build origin, not build integrity. The industry needs runtime behavioral analysis inside build pipelines, not just cryptographic receipts.

2. CI/CD Pipelines Are Attack Surface

Every pull_request_target trigger, every shared cache, every OIDC token flow is a potential entry point. Treat your CI/CD pipeline with the same rigor as your production Kubernetes cluster.

3. Developer Environments Are Infrastructure

.vscode/, .claude/, and IDE configuration directories must be treated as security-critical paths. They should be audited, monitored, and included in security scanning.

4. Network-Based Detection Is Insufficient

When exfiltration happens over decentralized, encrypted messaging protocols, traditional network monitoring fails. Endpoint-level behavioral detection becomes essential.

5. The Worm Model Changes Everything

A single compromised maintainer can cascade into hundreds of poisoned packages within hours. The blast radius of a supply chain worm is fundamentally different from a single malicious package.

Defending Against the Next Shai-Hulud

Here’s a concrete hardening checklist for your infrastructure:

  • Audit all pull_request_target workflows — Ensure they cannot execute arbitrary code from forks
  • Isolate GitHub Actions caches — Use unique cache keys per workflow and validate cache integrity
  • Pin dependencies to exact versions — Use lockfiles and hash verification
  • Enable npm/PyPI 2FA — Require MFA for all package publications
  • Monitor .vscode/ and .claude/ directories — Alert on unexpected modifications
  • Implement egress filtering — Monitor for connections to decentralized messaging infrastructure
  • Use ephemeral CI/CD runners — Never reuse build environments across jobs
  • Deploy endpoint detection — Behavioral monitoring on developer machines, not just servers
  • Restrict OIDC token scope — Minimize the permissions granted to CI/CD identity tokens
  • Adopt package curation policies — Use allow-lists or curated registries instead of pulling directly from public npm/PyPI

Final Thoughts

The Shai-Hulud worm is a wake-up call. It demonstrates that the modern software supply chain—built on implicit trust in package registries, CI/CD pipelines, and developer tooling—is fundamentally fragile.

TeamPCP didn’t need a zero-day. They didn’t need to breach a corporate network. They chained together misconfigurations in publicly documented CI/CD features, abused the trust model of OIDC and SLSA, and turned the open-source ecosystem’s greatest strength—its interconnectedness—into a propagation mechanism.

The sandworm is loose. The question is whether your infrastructure is built to survive it.

Stay safe out there. If you found this useful, share it with your team—especially your platform engineers and DevSecOps folks.