Mini Shai-Hulud supply chain attack: Why this campaign changes how defenders should think about trusted software

The Mini Shai-Hulud supply chain attack is not just another malicious package incident. This campaign abused legitimate release infrastructure including trusted publishing workflows, provenance-signed pipelines, and developer environments. These techniques are particularly successful at making malicious activity look normal because the code will pass most standard verification and integrity checks.

According to the TanStack postmortem, the compromised TanStack packages carried valid provenance attestations produced by the project's own GitHub Actions trusted publication pipeline. Even where provenance attestations were valid, provenance alone was insufficient. The campaign, attributed to threat actor TeamPCP, then used stolen publishing credentials to propagate the campaign across additional packages.

Many of the controls security teams have spent years implementing were designed to verify authenticity, not intent. In this campaign, authenticity checks would still pass while the software being delivered was compromised.

What happened in the Mini Shai-Hulud supply chain attack

As publicly reported across the security community, this campaign affected more than 170 packages across npm and PyPI and touched ecosystems with massive downstream reach. The attack targeted widely used developer tooling and libraries, including packages tied to frontend frameworks, AI SDKs, enterprise automation tooling, and search infrastructure.

At a high level, the campaign worked like this:

• Attackers hijacked a trusted publishing path by compromising the build process itself.
• Malicious package versions were published through legitimate workflows and carried valid provenance attestations.
• When installed, those packages stole credentials from developer machines and CI/CD runners.
• The malware then used those stolen credentials to publish more poisoned packages.
• Persistence mechanisms were added to survive cleanup attempts and continue credential theft.

This is what made the campaign worm-like. Each newly compromised environment could become a distribution point for the next wave.

Why this attack is different

It abused trusted release processes, not just package trust

The attacker hijacked a legitimate release pipeline rather than simply publishing obvious typosquats or fake packages. The malicious releases retained valid provenance signals, which highlights that authenticity checks alone were insufficient.

If your only or primary control checks whether a package came from the expected pipeline, that is not enough. The pipeline was the attack vector, and the Mini Shai-Hulud would appear legitimate in typical checks which verify and confirm which pipeline built an artifact, not whether the contents of the artifact are intentional.

It spread through identity, not just code

This campaign was heavily identity driven and operated within an ecosystem exhibiting extreme secrets sprawl. The scale of exposed secrets in the ecosystem gave it room to run: GitGuardian reported 28.65 million new hardcoded secrets publicly exposed on GitHub in 2025.

Rather than relying on one-time execution alone, it focused on stealing credentials across developer machines and CI/CD runners. Once attackers had those identities, software publishing itself became the propagation mechanism. It targeted developer environments as a persistence layer.

The campaign installed persistence hooks in developer tooling and local configuration paths, including IDE-related directories and AI-assisted coding environments. Persistence in .claude/settings.json (a SessionStart hook that re-executes on every Claude Code session) and .vscode/tasks.json (auto-runs on folder open) means that simply running "npm uninstall" alone does not remove it.

How the attack chain worked

While implementations varied by package and ecosystem, the campaign broadly combined supply chain compromise, credential theft, and self-propagation.

What the malware tried to steal

Reporting on the Mini Shai-Hulud supply chain attack indicates a broad collection scope. The goal was not just one token type. In Q3 2025, Sonatype found that 37% of malicious open-source packages target data exfiltration, and this campaign followed that same pattern. It was designed to harvest anything useful for lateral movement, persistence, and follow-on compromise.

Common targets included:

• Cloud provider credentials
• Package registry tokens
• CI/CD pipeline secrets
• Git credentials and source control tokens
• Kubernetes configuration files, service-account tokens, and credentials or tokens that grant access to secrets managers
• SSH keys
• Local developer configuration files
• AI developer tooling settings
• Cryptocurrency wallet data in some variants

Response teams should not think in terms of "rotate the npm token and move on." If a poisoned package executed in a sensitive environment, the blast radius is likely much larger.

Indicators that you may be affected

Security teams investigating potential exposure should look at both dependencies and endpoint behavior. This is not only a software composition problem.

Dependency-level signs

Start with:

• Lockfiles referencing affected versions
• Package installation logs from May 11 onward
• Unexpected lifecycle scripts such as preinstall or prepare
• Suspicious optional dependencies or Git-based package references
• Unusually large tarballs or embedded obfuscated files

Endpoint- and environment-level signs

Also hunt for:

• Unexpected changes in .vscode/ or .claude/ directories
• Unauthorized LaunchAgents or user-level systemd services
• New workflow files added to repositories
• Outbound connections to suspicious infrastructure during package install
• Package publish events that maintainers do not recognize
• Suspicious public repositories or commits created with stolen credentials

Network and behavioral signs

Leading incident reports also point to redundant exfiltration channels. That means defenders should not assume blocking one domain ends the risk. Watch for:

• Unusual API calls to code hosting platforms
• Traffic to known attacker-controlled domains, public code-hosting APIs used for exfiltration, webhook endpoints, Tor-related infrastructure, or IPFS gateways, if those were observed
• Sudden access to metadata services, local vaults, or token stores
• Process behavior that reads environment variables, token stores, shell history, package-manager credentials, or other secret-bearing files on developer workstations and CI runners

How to respond to the Mini Shai-Hulud supply chain attack

This is an incident that requires both security and IT operations coordination. An effective response usually follows a strict sequence.

Immediate actions

• Identify whether affected package versions were installed.
• Isolate impacted developer workstations and CI/CD environments before revoking credentials.
• Coordinate with IR so token revocation does not trigger known destructive logic on still-connected hosts.
• Look for persistence artifacts before making broad changes.
• Preserve forensic evidence where possible.
• Review whether any packages under your control were republished unexpectedly.

Why sequencing matters

The malware includes a dead man's switch. A persistence daemon (gh-token-monitor) polls GitHub every 60 seconds. When it detects token revocation (HTTP 40X response), it executes rm -rf ~/—a full home directory wipe. This means defenders must isolate compromised environments before revoking credentials. Doing it in the wrong order triggers the destructive payload. For that reason, mature response here is not just "revoke everything now." It is:

• Isolate first
• Inspect persistence
• Image if needed
• Then rotate and remediate in a controlled sequence

Teams that have invested in incident response and Security Operations are better positioned to coordinate that sequence across endpoints, identities, and forensic workflows.

What this incident says about software trust

The Mini Shai-Hulud supply chain attack exposes a blind spot many organizations still have: they equate signed, official, or provenance-backed with safe.

Those are still valuable signals. But they are not sufficient on their own.

A stronger model now includes all the following:

• Verifying where software came from
• Delaying adoption of newly published versions
• Restricting install-time script execution
• Monitoring runtime behavior during builds and installs
• Reducing secret exposure in CI/CD
• Watching developer endpoints with the same rigor used for servers

Practical hardening steps teams should implement now

The right long-term response is not panic-driven package avoidance. It is layered hardening.

Build and package controls

These are all part of a broader software supply chain defense strategy that assumes trusted workflows can still be abused.

Identity and secrets controls

• Reduce long-lived publishing credentials
• Tightly scope CI/CD identities
• Separate build, release, and deployment permissions
• Minimize secrets present on runners
• Regularly audit package publishing access and two-factor authentication bypass settings

Endpoint and developer environment controls

• Monitor IDE configuration paths and startup hooks
• Treat developer tooling directories as security-relevant, not benign
• Inventory where cloud credentials and registry tokens are stored
• Verify persistence removal, not just package deletion

What effective supply chain response requires

This is not only a software package vulnerability problem. It is an endpoint, identity, and operational response problem at the same time.

Bottom line: if developers or automated build systems in your organization installed affected components since May 11, treat those environments as compromised. Because propagation relied on stolen identities, each compromised environment could become a distribution point.

This is the first documented case of a self-spreading supply chain attack that produced malicious packages with valid, industry-standard provenance attestations. Supply-chain Levels for Software Artifacts (SLSA) worked as designed. The ecosystem assumed it solved more than it does. Provenance confirms which pipeline built an artifact, not whether the pipeline was behaving as intended.

The attacker did not forge a fake receipt. They broke into the kitchen and cooked a poisoned meal using the restaurant's own stove. The receipt was technically accurate.

TeamPCP (also tracked as DeadCatx3, PCPcat, ShellForce, CipherForce) has systematically targeted the trust chain itself:

• March 2026: Trivy, an open-source security scanner—the tools defenders use (Microsoft)
• April 2026: Bitwarden CLI, a password manager—credential stores
• May 2026: npm/PyPI ecosystem worm—the broader software supply chain

The group has announced a partnership with Vect, a ransomware-as-a-service operation (Unit 42). Attribution indicators include a Russian-locale kill switch (Microsoft). Whether one operator or multiple affiliates are involved, the pattern suggests supply chain attack tooling is maturing inside ransomware-affiliated networks.

Supply chain attacks are often precursors to more significant attacks, including ransomware, rather than isolated credential theft events. Recent campaigns abusing trusted software brands like Notepad++ and download channels reinforce that software distribution paths remain high-value targets.

For defenders, this breaks down into three phases and their timelines:

1. Immediate actions to prioritize (hours)

• Check lockfiles and CI logs for any affected package versions installed since May 11
• If exposure is confirmed, isolate the environment before revoking tokens
• Check for known-sample persistence names such as com.user.gh-token-monitor.plist and gh-token-monitor.service, and also hunt for functionally equivalent unauthorized LaunchAgents, user services, cron jobs, shell startup modifications, and IDE/tooling startup hooks
• Check .claude/ and .vscode/ directories for injected persistence payloads
• Rotate all credentials accessible from any exposed environment, not just npm tokens

2. Short-term actions (days)

• Audit dependency manifests, lockfiles, CI logs, caches, runner images, and any generated SBOMs for affected packages and versions, including packages tied to frontend, enterprise automation, search, and AI tooling
• If CI/CD runners had PyPI publishing credentials available while running compromised npm packages, rotate those too
• Review GitHub Actions workflows that use pull_request_target together with untrusted code checkout, write-scoped GITHUB_TOKEN, exposed secrets, or cache reuse across trust boundaries, because those combinations can enable workflow compromise

3. Strategic actions (this week and beyond)

• Minimum release age delays: Even a 3-day delay would have provided a defensive buffer against this campaign, aligning with CISA's guidance on mitigating fast-moving supply chain attacks. Implement via min-release-age in pnpm, or enforce through a proxy registry / artifact policy engine for package managers that don't support it natively.
• Pin dependencies to exact versions and enforce lockfiles, including their recorded integrity hashes
• Set ignore-scripts=true in .npmrc for CI environments
• Treat supply chain attacks as a precursor to broader enterprise compromise

Questions security teams should be asking now

Did any developer or CI environment install affected versions after May 11?

If the answer is yes, assume compromise until proven otherwise.

What secrets were present in those environments at execution time?

Focus on cloud, package publishing, source control, and deployment identities first.

Were any repositories or packages under your control modified or republished unexpectedly?

This campaign was self-propagating. Your environment may have been both a victim and a distribution point. If so, your publishing credentials may have been used to compromise others.

Can you verify removal of persistence from endpoints?

Do not stop at deleting node modules or reverting lockfiles.

Turning supply chain risk into actionable response with Tanium

Tanium Guardian and the Mini Shai-Hulud Supply Chain Compromise dashboard give security and IT operations teams a shared, real-time view of endpoint state across the developer attack surface:

• Help identify endpoints where impacted npm and PyPI packages may be running, using SBOM data where available
• Scope exposure surfacing machines with Node.js, Python, and AI tooling such as Claude Code installed
• Hunt for persistence indicators—LaunchAgents, user-level services, and IDE or tooling startup hooks—using pre-built questions that run against live endpoint telemetry
• Verify cleanup status across CI/CD runner configurations and credential exposure surfaces, not just package registries

Organizations with the Tanium agent already deployed can use existing Guardian content with no additional agent deployments required.

Response should not stop at registry or repository review. Developer endpoints and CI/CD runners are part of the attack path. Tanium lets security and IT operations confirm exposure, verify persistence removal, and coordinate remediation from the same current-state view rather than relying on static build artifacts or delayed manual checks.

FAQ about the Mini Shai-Hulud supply chain attack

Supply chain attacks like Mini Shai-Hulud raise questions that go well beyond standard incident response playbooks.

Below are some common questions security teams are asking about this campaign and what it means for software trust going forward.

Can valid package provenance still be trusted?

It can still be useful, but it should not be treated as a complete safety signal. Provenance tells you where something came from. It does not prove the pipeline was not abused.

Should teams revoke stolen tokens immediately?

Not blindly. In incidents with destructive revocation logic, isolation and investigation should come first so response actions do not trigger additional damage.

What is the most practical preventive control most teams are still missing?

A waiting period before consuming newly published package versions remains one of the simplest and most effective controls, especially against fast-moving supply chain events.

Why does this campaign matter beyond developers?

Because developer workstations and CI/CD runners often hold cloud credentials, deployment rights, and package publishing identities. Compromising them can quickly become a broader enterprise incident.

Tanium is designed to complement existing supply chain security efforts and controls by connecting package exposure, endpoint state, persistence validation, and response verification—so security and IT operations can act from the same real-time picture.
Schedule a demo today to learn how Tanium coordinates supply chain response across endpoints and identities.