Topic starter
11/06/2026 11:43 pm
TL;DR: A coordinated npm supply-chain campaign trojanized popular packages to run install-time payloads that scanned for GitHub, npm, and AWS credentials, then reused valid tokens for persistence, exfiltration, and lateral movement, according to Riptides. The attack succeeds because static secrets on disk or in CI turn a single malicious install into reusable access.
Editorial analysis by NHI Mgmt Group, based on content published by Riptides: “Shai-Hulud and the Secret Hunters: How npm Installs Turn into Intrusions”.
Key questions
Q: What breaks when npm install scripts can access long-lived credentials?
A: The install step stops being a safe execution boundary.
Q: Why do valid tokens make supply-chain attacks worse than simple secret leaks?
A: A valid token is already an access mechanism, not just evidence of compromise.
Q: What are the signs that build systems are exposing reusable secrets?
A: Look for credentials present in CI variables, dependency install logs, local caches, developer dotfiles, and workflow files that can be read by untrusted package code.
Practitioner guidance
- Eliminate long-lived credentials from build paths Remove static GitHub, npm, and cloud tokens from repositories, CI variables, images, and developer workstations so package installs cannot harvest reusable access.
- Bind non-human identity to workload context Issue credentials only for the workload that needs them and keep them out of disk-backed storage, build logs, and environment variables wherever possible.
- Reduce token reuse value Shorten TTLs, narrow scopes, and revoke tokens aggressively so a secret discovered during dependency execution cannot be reused for publishing or cloud access.
Bottom line: The campaign demonstrates that npm installs can become intrusion points when package code can reach static credentials in developer or CI environments.
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
12/06/2026 8:31 am
Static secret sprawl is the real supply-chain blast-radius problem: This campaign worked because reusable credentials were present where package code could reach them. The attacker did not need to defeat cryptography or break npm itself, only to find a credential that remained valid outside the workload that should have held it. The practitioner implication is clear: if a dependency install can read a usable secret, the blast radius is already too large.
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: Should teams prioritise secret removal or token rotation first in npm pipelines?
A: Remove secrets first. Rotation helps only when a token is already constrained, but the article shows that install-time malware can discover and validate credentials before defenders notice. Eliminating static secrets from build paths reduces both immediate exposure and the chance that rotation becomes a cleanup exercise after compromise.
👉 Read our full editorial: Static secrets make npm supply-chain attacks far easier to scale
This post was modified 1 day ago by NHI Mgmt Group