Notifications
Clear all
Topic starter
09/06/2026 11:44 pm
TL;DR: A compromise of the npm account “atool” poisoned more than 600 package versions across 323 widely used libraries, with 16 million weekly downloads and credential theft from CI/CD, cloud, and developer environments, according to Orca Security. The incident shows that build-time trust, not just runtime access, is now a primary identity attack surface.
NHIMG editorial — based on content published by Orca Security covering the Mini Shai-Hulud npm supply chain attack: LLMjacking: How Attackers Hijack AI Using Compromised NHIs
By the numbers:
- The attack published 637 malicious package versions in a single 22-minute burst.
- The affected packages were collectively downloaded approximately 16 million times per week.
- Within hours of the attack, over 2,500 public GitHub repositories were created using exfiltrated tokens as additional dead-drops.
Questions worth separating out
Q: What breaks when malicious npm packages execute during CI/CD installs?
A: The main failure is that package installation becomes code execution inside a trusted build context.
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 package installation risk is under control?
A: Look for three signals: scripts are blocked or tightly governed during install, runner memory and local secrets are minimized, and package provenance is checked before deployment.
Practitioner guidance
- Block script execution during dependency installs Use install modes that suppress lifecycle scripts in build and validation paths, and only allow scripts in controlled, reviewed pipelines.
- Reduce token scope in CI/CD runners Remove broad publish and cloud permissions from runners unless a workflow truly requires them, and prefer short-lived credentials with explicit task scope.
- Inventory exposed identities across the delivery chain Map where GitHub PATs, OIDC tokens, npm tokens, cloud keys, Vault credentials, SSH keys, and database strings can appear in developer and build environments.
What's in the full article
Orca Security's full research covers the operational detail this post intentionally leaves for the source:
- Exact package names and version families affected across the @antv ecosystem and related libraries
- Step-by-step remediation order for removing persistence artifacts before rotating exposed credentials
- Indicators of compromise for repository branches, workflow files, and suspicious npm publication activity
- Environment context for identifying which build servers and developer workstations need priority review
👉 Read Orca Security's analysis of the Mini Shai-Hulud npm supply chain attack →
Mini Shai-Hulud npm supply chain attack: what IAM teams need now?
Explore further
10/06/2026 2:11 am
Build-time trust is now an identity control surface, not just a software delivery concern. This compromise worked because package installation was treated as a low-risk mechanical step rather than an execution event with identity consequences. Once npm preinstall hooks can read memory, steal tokens, and publish onward, the boundary between dependency management and identity governance disappears. Practitioners should treat package install paths as governed execution points, not passive delivery plumbing.
A few things that frame the scale:
- 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.
- Secret remediation is not just slow. 44% of developers are reported to follow security best practices for secrets management, which shows the gap is behavioural as well as technical.
A question worth separating out:
Q: How should teams respond after a poisoned package is detected in their pipelines?
A: Contain the build environment first, then rotate any secrets that may have been present in memory, files, or tokens during install. After that, review repository branches, workflow files, and any unexpected package publication activity. The goal is to stop credential reuse and persistence before the compromise spreads into adjacent systems.
👉 Read our full editorial: Mini Shai-Hulud shows how npm supply chains steal CI/CD secrets
