A new “Mini Shai-Hulud” supply-chain wave has hit public package ecosystems, with malicious npm and PyPI releases tied to projects including TanStack, Mistral AI, Guardrails AI, OpenSearch, and UiPath.[1] The common risk is not only that a developer may install a bad package. In CI/CD, one compromised install step can expose package-registry tokens, GitHub tokens, cloud keys, and deployment secrets before anyone notices the version bump.
The Hacker News reported the campaign on May 12, 2026, describing it as a smaller Shai-Hulud-style worm that targets package installs and tries to steal credentials from developer and build environments.[1] The United Kingdom’s National Cyber Security Centre says affected packages include popular npm components and the PyPI package guardrails-ai==0.10.1, while warning that malicious package code may execute during install or import depending on the ecosystem and package.[2]
TanStack published a postmortem saying malicious versions of its npm packages were published on May 11 for a narrow window and that the issue was detected within minutes.[3] Its write-up is useful because it separates two things administrators often mix together: the public package versions that should be avoided, and the project’s own npm tokens or publishing workflow. TanStack says its npm tokens were not compromised and that the publish workflow itself was not compromised.[3]
Mistral AI also published a security advisory for compromised npm packages and a PyPI release, including mistralai==2.4.6 on PyPI.[4] Mistral says the PyPI payload could run on import on Linux systems and attempt credential theft, which is the detail that should make teams check notebooks, containers, workers, and automation jobs rather than only laptops.[4]
This is the same operational lesson we have already seen in other build-chain incidents, including the malicious Checkmarx Jenkins AST plugin and earlier poisoned RubyGems and Go modules used to steal CI secrets. The attacker does not need to compromise production first. A package install on a privileged build runner can be enough.
What teams should check first
Do not treat this as a “delete one package and move on” event. Public advisories are still being updated, and affected package lists can expand as maintainers audit caches and mirrors. The safe first move is to freeze automatic dependency updates long enough to answer where the affected versions ran.
| Area | Recommended check |
|---|---|
| Lockfiles and manifests | Search package-lock.json, pnpm-lock.yaml, yarn.lock, requirements.txt, Poetry, Pipenv, and generated SBOMs for affected package names and versions from NCSC, TanStack, and Mistral advisories.[2] |
| CI/CD history | Identify builds that ran dependency install steps during the exposure windows. Preserve logs before retention jobs rotate them. |
| Package caches | Inspect npm, pnpm, yarn, pip, Docker layer, artifact-proxy, and private-registry caches. A removed public package can still live in internal caches. |
| Secrets scope | Rotate tokens that were available to jobs using affected packages: npm, PyPI, GitHub/GitLab, cloud credentials, container registries, SSH deploy keys, and signing keys. |
| Runtime systems | Check containers, notebooks, scheduled workers, and developer images that may import affected Python packages even if no new install happened later. |
For JavaScript projects, the highest-value evidence is the exact package version installed and the build identity that installed it. For Python projects, import-time execution makes runtime inventory just as important. Mistral’s advisory specifically calls out the PyPI package behavior, so a production worker that imported the package can matter even if the install happened earlier in an image build.[4]
If an affected package ran where secrets were present, assume those secrets may be exposed. Rotate from a clean administrative workstation, invalidate old package tokens, review recent package publishes under your own accounts, and look for unexpected workflow changes. Also check for new repositories, altered CI files, unusual release artifacts, and tokens used from unfamiliar IPs. The blast radius follows the credentials, not the package name.
Finally, pin known-good versions while maintainers finish cleanup. Pinning is not a permanent substitute for patching, but it prevents an automated resolver from turning a transient public-registry problem into a local incident. Once maintainers confirm clean releases, update deliberately and keep the incident record tied to builds, lockfiles, and rotated secrets.
References
- Ravie Lakshmanan. “Mini Shai-Hulud Worm Compromises npm and PyPI Packages Across Major Projects.” The Hacker News, May 12, 2026. https://thehackernews.com/2026/05/mini-shai-hulud-worm-compromises.html
- National Cyber Security Centre. “Active supply chain compromise affecting npm and PyPI packages.” NCSC, May 12, 2026. https://www.ncsc.gov.uk/guidance/active-supply-chain-compromise-affecting-npm-and-pypi-packages
- TanStack. “npm Supply Chain Compromise Postmortem.” TanStack, May 12, 2026. https://tanstack.com/blog/npm-supply-chain-compromise-postmortem
- Mistral AI. “Security advisory: compromised npm and PyPI packages.” Mistral AI, May 12, 2026. https://docs.mistral.ai/resources/security-advisories
Related supply-chain alert: Laravel teams should also review the newer Laravel-Lang Composer package hijack, where rewritten version tags loaded a credential stealer through Composer autoloading.
Related update: A later Miasma wave also hit @redhat-cloud-services npm packages; see our follow-up on the Red Hat npm credential-stealing worm for the June 2026 package list and CI secret-rotation checks.
Leave a Comment