Mini-Shai-Hulud shows how package installs can steal NHI secrets

At a glance

What this is: Mini-Shai-Hulud is a supply-chain compromise that weaponised package installation to harvest non-human credentials from developer and CI environments.

Why it matters: It matters because IAM, PAM and NHI teams need to treat package install paths, runner environments and developer tooling as credential-bearing surfaces, not just software delivery channels.

By the numbers:

• The attack published malicious versions of at least 235 packages across npm and PyPI.
• The @tanstack/* packages were first compromised across 42 npm packages before the campaign spread further.
• The attackers targeted 62 unscoped npm packages with plausible-looking names.

Context

Package installation is not just code acquisition. In this campaign, the install path itself became the execution surface, with malicious dependency behaviour running before review, before sandboxing and before application logic could intervene.

For IAM and NHI programmes, the important change is that developer workstations, CI runners and build tools often hold secrets with enough privilege to become high-value targets. Once those credentials are reachable from package lifecycle hooks or import-time payloads, software supply chain abuse turns into identity compromise.

The attack is a strong example of how modern supply chain compromise blends software delivery with secret theft. That makes lifecycle governance, environment isolation and token scoping part of the same control problem rather than separate workstreams.

Key questions

Q: What fails first when a malicious package can read NHI secrets during install?

A: The first failure is usually the assumption that package installation is non-sensitive. If install-time code can read environment variables, credential files or runner metadata, secret exposure happens before the application is even exercised. The control that fails is boundary enforcement between software delivery and credential-bearing execution contexts.

Q: Why do CI runners make supply-chain malware worse than a normal developer compromise?

A: CI runners often hold reusable cloud, registry, and release credentials in one session, so a single poisoned package can reach multiple identities at once. The result is not just code execution but cross-system credential reuse, workflow tampering, and downstream package publication from a trusted environment.

Q: What signs indicate a package install attack has moved beyond the package itself?

A: Look for unexpected file changes in developer tooling, outbound connections during install, and secret access from contexts that normally should not touch them. Those signals suggest the attack has shifted from simple package compromise to environment-level persistence or credential theft.

Q: How should organisations respond when a dependency compromise also affects runner integrity?

A: They should treat the incident as both a software supply-chain event and a host integrity event. Dependency removal alone is not enough if the runner or workstation may have been modified, because persistence can survive package cleanup and re-trigger credential theft.

Technical breakdown

Install-time execution turns package managers into attack surfaces

npm and PyPI both support lifecycle behaviour that runs code during installation or import. In Mini-Shai-Hulud, malicious packages used that behaviour to execute payloads before the application ran, which means static trust in the package name or version was not enough. The npm path used optional dependencies and prepare hooks, while the PyPI path used import-triggered droppers and a staged payload. In both cases, the attacker leveraged legitimate package mechanics to hide execution inside normal developer workflows.

Practical implication: treat package lifecycle hooks as executable content and inspect install-time behaviour, not just source diffs.

Why NHI secrets are exposed in build and developer environments

The payload searched local files and environment variables for AWS, GitHub, Vault, Kubernetes, GitLab, CircleCI and npm credentials. That is a classic NHI problem because these secrets are often long-lived, broadly scoped, or present in multiple environments that should not share trust. A single developer session or CI runner can therefore contain enough privilege for downstream repository access, cloud access, or package publishing. The issue is not merely theft of a token. It is the presence of multiple secret types in places where package execution can reach them.

Practical implication: inventory where NHI secrets exist in developer and CI systems and narrow the scope of every credential that can be touched by tooling.

Persistence makes dependency removal an incomplete response

The campaign did not stop at exfiltration. Evidence of modifications to developer tooling such as Claude and VS Code setup files suggests the attackers also tried to persist execution beyond the compromised package. That matters because simply removing a malicious dependency may not evict the implant if the environment itself has already been altered. This creates a blended incident pattern: supply-chain entry, secret theft, and environment persistence. For defenders, the remediation unit is the workstation or runner image, not only the package lockfile.

Practical implication: verify host and runner integrity after package compromise, not just package version state.

Threat narrative

Attacker objective: The attacker’s objective was to steal reusable non-human credentials from trusted development and build environments and preserve access long enough to reuse them elsewhere.

1. Entry occurred through malicious package versions published across npm and PyPI, including official scopes and plausible typosquats.
2. Credential harvesting happened when install-time or import-time payloads searched developer and CI environments for AWS, GitHub, Vault, Kubernetes and publishing tokens.
3. Impact came from exfiltration of non-human credentials and possible persistence in developer tooling, widening the blast radius beyond the initial package compromise.

Breaches seen in the wild

• Shai-Hulud npm worm first wave 2025: The first Shai-Hulud wave used stolen npm tokens to trojanise 500+ packages, starting with tinycolor, and leaked developer and CI secrets on GitHub.
• GitHub internal repositories breach 2026: A stolen GitHub CLI token let attackers publish a poisoned Nx Console extension that harvested secrets and exfiltrated 3,800 GitHub repos.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Package installation has become an identity control point, not just a software delivery step. Mini-Shai-Hulud shows that the boundary between software supply chain security and identity security is thinner than many programmes assume. When package lifecycle hooks can access environment variables, cloud metadata and CI tokens, the install process itself becomes part of the credential attack surface. Practitioners need to treat package execution as an identity event, not only a code provenance event.

NHI governance fails when secrets are placed in environments that package code can reach. The problem is not that tokens exist, but that they are often available in developer workstations, runner images and shared build contexts with more privilege than the install step should ever need. That creates a credential exposure plane that conventional review and static scanning do not remove. The governance answer is to minimise where secrets live and how broadly they can be read.

Environment persistence is the named failure mode this campaign illustrates. A poisoned dependency can be removed while altered tooling remains behind, which means the compromise is not bounded by the package registry event. This is a specific control gap: organisations often track vulnerable artifacts more reliably than compromised execution environments. The practitioner conclusion is to define response around host and runner integrity, not only dependency remediation.

Identity scope compression is the right concept for this incident. The campaign succeeded because too many unrelated secrets were reachable from too few execution contexts. In identity terms, that is a failure to compress privilege to the smallest possible session, runner or workspace boundary. Once a package can see credentials it should never have touched, blast radius becomes the real control metric.

Supply-chain compromise now demands NHI lifecycle thinking. The most relevant lesson is not simply that attackers can steal tokens, but that they can harvest credentials whose lifecycle was never designed for hostile code execution. OWASP NHI Top 10 concerns such as secret leakage, overprivileged NHI and long-lived secrets are directly relevant here, alongside MITRE ATT&CK credential access and lateral movement. The field should treat package installs as a place where NHI governance either holds or fails.

From our research library:

• 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.

What this signals

Identity scope compression: supply-chain attacks become far more damaging when package execution can touch broad, shared credential stores. The practical response is to reduce how many secrets are present in any one build or developer context, because install-time abuse converts excess privilege into immediate blast radius.

Mini-Shai-Hulud reinforces a wider programme shift for practitioners: package trust, runner hardening and secret governance now need to be managed together. If a dependency can execute before review, the control point moves earlier than code scanning and deeper than the artifact registry.

For practitioners

• Scan package installs for malicious lifecycle behaviour Inspect dependency manifests, prepare scripts, preinstall hooks and import-time execution before allowing new packages into developer or CI environments.
• Reduce secret exposure in build and developer environments Remove AWS, GitHub, Vault, npm and CI tokens from contexts that package code can reach, and scope any remaining credentials to the minimum required runtime.
• Rotate every credential touched by compromised runners or workstations Treat exposed machine credentials, PATs, OIDC tokens and publishing tokens as compromised if they were present in the affected environment during the attack window.
• Check for host persistence beyond dependency removal Review developer tooling files, runner images and workspace startup scripts for unauthorized modifications that could relaunch payloads after the package is deleted.
• Audit egress and install telemetry from the compromise window Look for unexpected connections to the reported command-and-control and exfiltration destinations in package install logs and CI build logs.

Key takeaways

• Mini-Shai-Hulud shows that package installs can become credential-harvesting events when developers and runners expose NHI secrets to untrusted code.
• The article reports at least 235 malicious package versions and highlights how official scopes, typosquats and lifecycle hooks widened the attack surface.
• The limiting control is not only dependency removal but shrinking secret reach, rotating exposed tokens and checking for host persistence after compromise.

Key terms

• Install-Time Payload: An install-time payload is malicious behaviour that runs when software is installed rather than when it is later executed. This matters because package lifecycle hooks can read environment secrets, fetch remote content, or implant code before standard review tools have a chance to inspect the final state.
• NHI Secret Exposure: The leakage of machine credentials such as API keys, tokens, certificates or cloud access secrets from places where untrusted code can read them. It is a governance failure because the secret existed in a reachable context, not merely because it was stolen.
• Runner Environment: A build or CI execution context that processes code, installs dependencies and often contains tokens needed for source control, cloud access or publishing. If compromised, it can become both the entry point and the blast-radius amplifier for supply-chain abuse.
• Lifecycle Hook: A lifecycle hook is code that runs automatically at defined stages of package installation or build processing, such as preinstall or postinstall. These hooks are powerful because they can execute before deeper inspection or controls are applied, making them a common abuse path in supply chain attacks.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management and workload identity. It helps practitioners connect identity controls to the build and runtime environments where modern attacks now operate.