Notifications
Clear all
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.
NHIMG editorial — based on content published by Checkmarx: analysis of the Shai-Hulud second-coming npm worm
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes
Questions worth separating out
Q: What breaks when malicious packages can execute during installation?
A: Traditional dependency scanning becomes too late because the package has already run.
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: How should organisations reduce the impact of malicious package worms?
A: They should prevent untrusted packages from executing, isolate build hosts, and keep publishing identities separate from normal developer access.
Practitioner guidance
- Inventory package-publishing identities and CI/CD tokens Map every GitHub, npm, and pipeline credential that can publish, modify, or install software.
- Block malicious packages before installation Add pre-install controls at developer endpoints, build systems, and private registries so known malicious versions never execute.
- Separate build trust from developer convenience Remove broad write access from standard developer tokens and require dedicated publishing identities for release activity.
What's in the full article
Checkmarx's full article covers the operational detail this post intentionally leaves for the source:
- How Malicious Package Protection flags infected versions across npm, Maven Central, PyPI, and other registries
- How the Malicious Package Identification API can block package installation before code reaches the build step
- How the research team validates suspicious packages before they are added to the malicious package database
- How Checkmarx AI Developer Assist surfaces protection directly inside the developer workflow
👉 Read Checkmarx's analysis of the Shai-Hulud second-coming npm worm →
Shai-Hulud npm worm: what security teams need to act on?
Explore further
02/08/2026 1:17 pm
Malicious packages are identity attacks disguised as software attacks. The core security failure is not only that attacker code is installed, but that the code can reach usable identities inside developer and pipeline environments. Once a package steals tokens or service credentials, the campaign stops being a simple software supply chain event and becomes NHI abuse. That is why dependency controls, secrets governance, and identity scoping must be treated as one control plane, not three. Practitioners should assume the package itself is only the carrier.
A question worth separating out:
Q: What frameworks help govern malicious package and secret exposure risk?
A: MITRE ATT&CK helps map credential access and lateral movement, while NIST SP 800-53 and NIST CSF support access control, monitoring, and recovery. For identity-specific software supply chain controls, OWASP NHI is also relevant because stolen tokens and repository credentials behave as non-human identities in practice.
👉 Read our full editorial: Shai-Hulud-style npm worms expose the limits of supply chain controls
