Topic starter
18/08/2026 2:22 pm
TL;DR: On May 11, 2026, a coordinated supply-chain attack published malicious versions of at least 235 packages across npm and PyPI, with install-time payloads stealing AWS, GitHub, Vault, and CI tokens, according to FOSSA. The incident shows that package installation itself has become an identity exposure point when non-human credentials are reachable from developer and build environments.
Editorial analysis by NHI Mgmt Group, based on content published by FOSSA: “Responding to the Latest Mini-Shai-Hulud Supply Chain Attack”.
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.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: Mini-Shai-Hulud shows that package installs can become credential-harvesting events when developers and runners expose NHI secrets to untrusted code.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
18/08/2026 3:14 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Mini-Shai-Hulud shows how package installs can steal NHI secrets