Topic starter
16/01/2026 2:09 pm
TL;DR: A new Shai-Hulud wave poisoned more than 800 npm packages and populated over 25,000 GitHub repositories with stolen secrets, while also creating persistent GitHub runners for remote access, according to Backslash Security. The incident shows that package trust, build automation, and secret handling remain inseparable NHI governance problems, not isolated developer hygiene issues.
Editorial analysis by NHI Mgmt Group, based on content published by Backslash Security: “Shai-Hulud Strikes Again: Massive npm Attack Exposes Thousands of Secrets”.
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 compromised build runners and secrets create such a large blast radius?
A: Build runners often reuse persistent credentials across many repositories and environments, so one infected execution path can expose more than a single project.
Q: What are the signs that an npm supply chain attack has reached secret-exposure stage?
A: Look for unusual repository creation, rapid growth in secret-bearing artifacts, unexpected CI activity, and new runner registrations tied to package execution.
Practitioner guidance
- Constrain package execution in build pipelines Block unnecessary preinstall and postinstall hooks, and only allow dependency execution in controlled pipelines that do not expose production secrets.
- Separate build identities from sensitive cloud access Use dedicated build credentials with tightly scoped permissions so a compromised package cannot reach cloud keys, deployment tokens, or environment secrets.
- Inventory and rotate exposed machine secrets Assume any host that ran a compromised package may have leaked tokens, API keys, or environment variables, then revoke and replace those credentials immediately.
Bottom line: This attack shows that a malicious package can become both an execution path and a credential-harvesting path inside trusted automation.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 4 days ago by NHI Mgmt Group
08/10/2026 5:33 pm
Package trust has become an NHI governance boundary: The security question is no longer whether an npm package is signed or popular, but whether it can execute inside an environment that already contains machine credentials. That shifts the control boundary from software provenance alone to identity-bearing build and install paths. Practitioners should treat dependency execution as part of NHI governance, not a separate developer concern.
A few things that frame the scale:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: How should teams respond when a self-hosted repository exposes secrets?
A: Treat the repository as only one part of the problem. Revoke and rotate the exposed secrets, review the downstream SaaS and storage accounts they can reach, and verify whether other credentials were stored in the same location. Self-hosted systems demand the same lifecycle discipline as any production identity platform.
👉 Read our full editorial: Shai-hulud npm attacks expose why NHI controls still fail