TL;DR: Mini Shai-Hulud injected malicious code into ten official TanStack package releases in under six minutes and used stolen GitHub, npm, and CI/CD secrets to self-propagate across projects, according to Arnica. The incident shows that package trust now depends on governed secret handling, not just publisher reputation.
NHIMG editorial — based on content published by Arnica covering the Mini Shai-Hulud TanStack package worm: How to Check for Impacted TanStack Packages in Your SBOM
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
Questions worth separating out
Q: What breaks when a compromised package can read secrets during installation?
A: The main failure is that package installation becomes an identity event.
Q: Why do CI/CD secrets create such a large blast radius in supply chain attacks?
A: CI/CD secrets are often shared across build, publish, and cloud tasks, so one exposed token can touch many systems at once.
Q: How do security teams know whether a package advisory has created real identity exposure?
A: They should check whether affected build or developer environments stored cloud keys, SSH keys, API tokens, or SaaS access at the time of installation.
Practitioner guidance
- Inventory build-time secrets as NHI assets Map GitHub tokens, npm tokens, CI/CD credentials, and any other release-path secrets to owners, scopes, and expiry dates.
- Restrict package install behaviour in pipelines Disable script execution where possible, isolate install jobs, and block secret access from package build steps that do not need it.
- Reduce propagation paths from compromised releases Separate publishing credentials from build credentials, use short-lived tokens for release actions, and require re-authentication for package publication.
What's in the full article
Arnica's full blog post covers the operational detail this post intentionally leaves for the source:
- The specific SBOM search workflow for identifying impacted @tanstack packages across source repositories and container images.
- The celebrity vulnerability database approach Arnica uses to map the Mini Shai-Hulud campaign to affected package versions.
- The DepsGuard configuration details for cooldown, ignore-scripts, and package-manager hardening.
- The practical steps for tracing whether an internal package was published by a compromised pipeline.
👉 Read Arnica's analysis of the Mini Shai-Hulud TanStack supply chain worm →
Mini Shai-Hulud and package worms: what IAM teams need to watch?
Explore further
Package worms are really secret-governance failures: the attack succeeded because CI/CD tokens were available to be harvested and reused, not because package trust was inherently broken. In practice, the release pipeline became an identity propagation layer. That is why NHI governance has to extend into build systems, where short-lived, narrowly scoped secrets matter more than publisher reputation alone.
A few things that frame the scale:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
A question worth separating out:
Q: Which controls matter most when a supply chain worm is self-propagating?
A: The highest-value controls are short-lived release credentials, install-time script restrictions, secret isolation in build jobs, and rapid revocation procedures. You need to prevent a compromised pipeline from becoming a publisher for the next malicious version. That means controlling both the package path and the credentials that can advance it.
👉 Read our full editorial: Mini Shai-Hulud shows why supply-chain worms are NHI problems