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.
NHIMG editorial — based on content published by Riptides: Shai-Hulud and the Secret Hunters, an analysis of npm installs turning into intrusions through compromised non-human identities
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.
Questions worth separating out
Q: How should security teams handle reusable secrets in npm build and CI environments?
A: They should remove reusable secrets from build paths entirely and replace them with workload-bound credentials that are issued only when needed.
Q: Why do static service tokens increase supply-chain compromise risk?
A: Static service tokens increase risk because they remain valid long enough for malware to discover, copy, and reuse them across multiple systems.
Q: What do teams get wrong about secret scanning in CI pipelines?
A: They often assume detection is enough, when the real problem is that a valid token can be used before the alert is triaged.
Practitioner guidance
- Remove reusable credentials from build paths Audit repositories, package configuration, CI variables, and local dev profiles for long-lived tokens, then replace them with workload-bound or brokered credentials that never land on disk.
- Force immediate revocation on secret exposure When a token is discovered in a build environment, revoke it first and investigate later, because validation-ready malware can use the credential before the next review cycle completes.
- Lock down package-install execution Separate dependency installation from privileged runtime paths, restrict outbound network access during install, and prevent lifecycle hooks from reaching secrets stores or cloud metadata.
What's in the full article
Riptides' full research covers the operational detail this post intentionally leaves for the source:
- Step-by-step GitHub and AWS deployment examples for kernel-anchored, secretless credential injection.
- Concrete configuration patterns for short-lived tokens, OIDC federation, and workload-bound identity.
- Two worked scenarios showing how install-time malware fails when credentials never land on disk.
- Implementation notes for using SPIFFE-based identity where workload federation is already in place.
👉 Read Riptides' analysis of Shai-Hulud and secret-hunting npm packages →
npm supply-chain secret hunting: what IAM teams need to know?
Explore further
Static secret persistence is the failure mode this campaign exploits. The attack works because credentials were still available in files, environment variables, and CI contexts after they should have been removed from reach. That is not a tooling gap alone, it is a governance assumption that the credential remains benign until a human notices exposure. Practitioner conclusion: treat persistence of reusable secrets as the core risk, not the package that first touched them.
A few things that frame the scale:
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to The State of Secrets Sprawl 2026.
- AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.
A question worth separating out:
Q: How do IAM and NHI teams reduce lateral movement after a leaked token?
A: They should trace every system the token can reach, then cut off any standing privilege that extends beyond the original workload. The token’s effective blast radius matters more than where it was found. If the same credential can reach source control, CI, and cloud APIs, it needs immediate containment across all three.
👉 Read our full editorial: Static secrets make npm supply-chain attacks far easier to scale