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.
Editorial analysis by NHI Mgmt Group, based on content published by Orca Security: “Massive npm Supply Chain Attack Compromises AntV Ecosystem, Steals CI/CD Secrets at Scale”.
By the numbers:
- The attack poisoned over 600 versions of 323 widely-used packages, according to Orca Security.
- Those packages were collectively downloaded approximately 16 million times per week, according to Orca Security.
- The attacker published 637 malicious package versions in a single 22-minute burst, according to Orca Security.
Key questions
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: What signs suggest a supply chain worm is using build identities for propagation?
A: Look for unexpected package publication, unauthorized repository creation, suspicious dependency updates, new branches or commits that look like maintenance noise, and repeat secret access from build environments.
Practitioner guidance
- Harden package installation paths Run dependency installs with scripts disabled where feasible, and isolate any package execution that must occur during build steps.
- Remove persistent secrets from runners Replace long-lived credentials in CI/CD environments with short-lived, scoped tokens and ensure build jobs cannot read unrelated cloud or registry secrets from memory or disk.
- Rotate exposed credentials in a strict order Revoke and regenerate package registry tokens, cloud keys, GitHub secrets, Kubernetes credentials, SSH keys, and database access after confirming persistence hooks are removed.
Bottom line: A poisoned npm package can turn trusted build steps into credential-extraction points, which makes CI/CD identity a first-class attack surface.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 1 day ago by NHI Mgmt Group
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
11/06/2026 1:15 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
12/06/2026 2:50 am
Build-time trust is now an identity problem, not just a supply chain problem. The attacker did not need to break runtime application controls when the package install path already carried execution privilege and secret access. That shifts governance from code provenance alone to the identity of the runner, the publishing workflow, and the secrets available during installation. Practitioners need to treat build-time trust as governed access, not assumed trust.
A few things that frame the scale:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: How should teams respond when package trust is compromised in CI/CD?
A: Treat the incident as both a software supply chain event and an identity incident. Remove persistence first, quarantine affected runners, revoke and reissue exposed credentials, and then rebuild from known-clean package versions before restoring normal pipeline operation.
👉 Read our full editorial: Mini Shai-Hulud shows how npm supply chains steal CI/CD secrets
This post was modified 1 day ago by NHI Mgmt Group