Topic starter
02/08/2026 12:15 pm
TL;DR: A self-replicating npm package campaign stole GitHub, NPM, and CI/CD credentials, spread through more than 770 packages and 27,000 repositories, and destroyed user directories when credential theft failed, according to Checkmarx. The incident shows that supply chain controls must stop malicious code before installation, not just detect compromised dependencies after the fact.
Editorial analysis by NHI Mgmt Group, based on content published by Checkmarx: “How Checkmarx Defends Against the Shai-Hulud Second Coming Malicious Package Campaign”.
By the numbers:
- The campaign had spread through over 770 npm packages at the time of writing.
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 CI/CD credentials make supply chain attacks much worse?
A: CI/CD credentials often sit at the centre of publish, build, and deployment workflows, so one stolen token can reach many repositories and environments.
Q: What are the signs that malicious package controls are failing?
A: Common signs include package installation occurring before trust checks, unexplained CI/CD token use, unexpected dependency changes, and repository activity tied to compromised developer accounts.
Practitioner guidance
- Block malicious packages before installation Enforce pre-install package screening in CI/CD, developer IDEs, and registry access paths so suspicious npm artifacts never reach execution.
- Govern registry and pipeline credentials as NHIs Inventory GitHub, NPM, and CI/CD tokens, scope them tightly, rotate them aggressively, and revoke unused secrets quickly.
- Treat package publishing rights as high-risk access Review who can publish, modify, or recover packages and repositories, then apply separation of duties to reduce blast radius.
Bottom line: The core risk is not hidden weakness in a legitimate dependency, but attacker code published as a dependency and executed on install.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 1:17 pm
Malicious packages are now a primary control boundary, not a secondary software quality issue. When the package is the payload, the security decision happens before installation, not after code review or dependency inventory. That changes the control model for supply chain security, because detection alone does not prevent execution. Practitioners should treat package admission as a high-risk trust decision, not a routine procurement step.
A question worth separating out:
Q: How should security teams respond when a package worm deletes developer directories?
A: Treat it as both a supply chain compromise and an endpoint incident. Isolate affected workstations, revoke exposed credentials, block the malicious package version, and check whether publishing or repository access was abused to spread the worm further. Recovery has to cover builds, endpoints, and identity assets together.
👉 Read our full editorial: Shai-Hulud-style npm worms expose the limits of supply chain controls