TL;DR: A credential-stealing worm poisoned 32 @redhat-cloud-services npm packages in a 72-second burst, then harvested SSH keys, tokens, and cloud secrets during install before committing them to attacker-controlled repos, according to AccuKnox. The incident shows why kernel-level runtime enforcement now matters more than after-the-fact detection when trusted software can become an identity theft vehicle.
NHIMG editorial — based on content published by AccuKnox: Red Hat NPM Supply Chain Attack: Runtime Defense Case Against 32 Poisoned Packages in 72 Seconds
By the numbers:
- The worm poisoned 32 @redhat-cloud-services npm packages in a 72-second burst.
- The affected packages carried close to 10 million collective downloads.
- OX Security found stolen credentials in over 210 GitHub repositories.
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 build runners create such high-risk NHI exposure?
A: Build runners often contain the credentials that let automation act across source control, cloud platforms, and container systems.
Q: What signs suggest a supply chain attack is moving faster than detection tools?
A: Look for exfiltration that completes during package install, unusual repository creation from build identities, and token reuse from accounts that should only publish software.
Practitioner guidance
- Restrict install-time execution in CI pipelines Block or tightly whitelist npm lifecycle hooks such as preinstall and postinstall on build runners that handle privileged credentials.
- Separate build secrets from broad-purpose credentials Move SSH keys, cloud tokens, and repository tokens out of shared runtime locations and reduce what any single runner can read.
- Enforce inline denial on sensitive file paths Use kernel-level policy to deny unauthorised reads of environment variables, secret files, and token stores before the action returns.
What's in the full article
AccuKnox's full analysis covers the operational detail this post intentionally leaves for the source:
- Kernel-level enforcement examples showing how eBPF and Linux Security Modules block the attack path
- The runtime policy matrix for denying unauthorised process execution, file access, and egress
- How the xBOM and SBOM workflow helps identify affected builds after a dependency compromise
- The live attack flow shown in the console, including how the denial happens before the payload completes
👉 Read AccuKnox's analysis of the Red Hat npm supply chain attack and runtime defense →
Poisoned npm packages and runtime defense: are your controls fast enough?
Explore further
Install-time code execution is now a governance failure, not just a developer convenience risk. The attack worked because npm lifecycle hooks let untrusted code run before the application even starts. That means package trust, execution trust, and secret trust cannot be managed as separate problems. Practitioners should treat install hooks as an execution boundary in policy design, not as a harmless setup feature.
A few things that frame the scale:
- The non-human identity governance gap is already measurable: only 19.6% of security professionals express strong confidence in their organisation's ability to securely manage non-human workload identities, according to The 2024 Non-Human Identity Security Report.
- A separate finding shows 88.5% of organisations acknowledge their non-human IAM practices lag behind or merely match their human identity and access management efforts, according to the same report.
A question worth separating out:
Q: How should security teams respond to poisoned package publishing rights?
A: Treat package publishing as privileged access and apply tighter lifecycle control to the tokens and automation identities that can publish. Review scope ownership, rotate high-risk tokens, and reduce the number of identities that can republish trusted software into public registries.
👉 Read our full editorial: Runtime defense for poisoned npm packages: what stops AI-era theft