Notifications
Clear all
Topic starter
09/06/2026 11:54 pm
TL;DR: The Mini Shai-Hulud compromise affected TanStack, Mistral AI, UiPath and 160-plus npm and PyPI packages, and used GitHub Actions, stolen OIDC tokens and runtime payloads to spread malicious releases across developer and CI environments, according to Orca Security. Package provenance did not stop the abuse because the attack executed from trusted workflows and valid tokens.
NHIMG editorial — based on content published by Orca Security: Mini Shai-Hulud supply chain compromise and credential worm behavior
By the numbers:
- The attack affected 373 malicious package-version entries across 169 npm package names and 2 PyPI packages.
- The compromise reached over 160 additional npm and PyPI packages.
Questions worth separating out
Q: What fails when package provenance is trusted too much in a supply chain compromise?
A: Provenance fails when the publishing identity is already compromised or attacker-influenced.
Q: Why do short-lived OIDC tokens still create meaningful supply chain risk?
A: Short-lived tokens still create risk because attackers only need them during the brief window when they are present in memory or workflow state.
Q: What should teams do when a package ecosystem attack reaches CI runners and developer workstations?
A: Teams should isolate the affected execution environments, identify persistence artefacts, and rotate every credential that may have been exposed, including GitHub, npm, cloud, and vault tokens.
Practitioner guidance
- Split trusted release workflows from untrusted pull request paths Prevent pull_request_target and similar high-trust workflow triggers from sharing caches, artifacts, or credentials with release jobs.
- Treat runner memory and logs as secret-bearing surfaces Harden CI runners so OIDC tokens, npm credentials, cloud keys, and vault tokens are not recoverable from process memory, debug output, or persisted workspace files.
- Reduce package publish rights to the smallest viable set Inventory every account that can publish or update packages, then remove broad access and separate build execution from release authority.
What's in the full article
Orca Security's full report covers the operational detail this post intentionally leaves for the source:
- The full exploit chain across GitHub Actions, cache poisoning, OIDC token extraction, and malicious package publication.
- Persistence indicators for gh-token-monitor on macOS and Linux, including file paths defenders should check first.
- The complete list of affected npm namespaces and PyPI package versions, useful for precise exposure triage.
- Blocking and containment guidance for the typosquat domain, Session network channel, and GitHub API dead drops.
👉 Read Orca Security's analysis of the Mini Shai-Hulud supply chain compromise →
Mini Shai-Hulud supply chain worm: what IAM teams need to know?
Explore further
10/06/2026 2:26 am
Trusted workflow identity is the new supply chain attack surface. This compromise worked because GitHub Actions, package publishing, and federated tokens were treated as separate layers when they were actually one delegated trust chain. OWASP-NHI and NIST-CSF both point to the same conclusion: if a build runner can mint, steal, or reuse publishing credentials, it is already an identity node with blast-radius potential. Practitioners should stop viewing CI as a neutral execution plane and treat it as a privileged identity domain.
A few things that frame the scale:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to The State of Secrets Sprawl 2026.
- 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and are 13% more likely to be categorised as critical than code-based leaks.
A question worth separating out:
Q: How should security teams reduce the chance of another npm worm spreading through build identity?
A: They should separate build, test, and release identities; limit who can publish packages; and block workflows that allow untrusted code to influence trusted release paths. Continuous monitoring must cover package lifecycle hooks, runner memory exposure, and any identity that can mint or reuse publishing credentials.
👉 Read our full editorial: Mini Shai-Hulud shows how npm supply chains become credential worms
