Topic starter
01/12/2025 1:46 pm
TL;DR: Unosecur says the Shai-Hulud 2.0 npm supply chain attack compromised maintainer accounts, shipped malicious package versions, and exfiltrated cloud credentials, GitHub tokens, and CI/CD secrets into more than 25,000 attacker-controlled repositories. Package trust is no longer the control boundary when identity posture decides how far supply-chain malware can move.
Editorial analysis by NHI Mgmt Group, based on content published by Unosecur: “Shai-Hulud 2.0: Responding to the 2025 npm Supply Chain Attack”.
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 standing CI/CD tokens create so much risk in supply chain attacks?
A: Standing tokens remain usable long after the moment they were created, so a compromise can persist through normal operations and even through partial remediation.
Q: How do teams know if a dependency compromise has become a persistence problem?
A: Look for unrecognised self-hosted runners, unexpected workflows, new branches, repeated secret access, and tokens being used from places they should never reach.
Practitioner guidance
- Restrict install-time script execution Block or tightly gate npm lifecycle scripts in CI/CD and other build systems that process unvetted dependencies, especially where secrets are present.
- Inventory exposed cloud and GitHub credentials Map every cloud key, GitHub token, CI/CD credential, npm token, and SSH key reachable from build and developer contexts, then revoke anything that was exposed.
- Replace reusable secrets with short-lived scoped credentials Remove long-lived secrets from pipelines and local developer environments, and move to short-lived credentials with tight scope wherever installation-time code can run.
Bottom line: The incident shows that npm supply chain compromise can become cloud identity abuse when build environments expose reusable secrets.
What's in the full article
Unosecur's full blog covers the operational detail this post intentionally leaves for the source:
- The exact malware behaviour across preinstall, exfiltration, runner registration, and republishing steps
- The list of credential types harvested from developer and CI/CD environments
- The GitHub artefacts, workflow tricks, and repository patterns used to hide stolen data
- The post-incident cleanup actions for revoking tokens and checking for persistence
👉 Read Unosecur's analysis of the Shai-Hulud 2.0 npm supply chain attack →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
07/10/2026 6:21 pm
Package trust is now an identity problem, not a code-review problem: the moment a dependency can execute during install, package provenance stops being the only boundary that matters. In this campaign, npm delivery became a credential collection mechanism because build and developer contexts already contained usable cloud and automation secrets. The practitioner conclusion is simple: identity posture now determines the blast radius of dependency risk.
A few things that frame the scale:
- The blast radius of the Salesloft-Drift OAuth supply chain attack was 10 times greater than earlier incidents in which attackers breached Salesforce directly.
A question worth separating out:
Q: How should teams respond when a malicious npm package can steal build secrets?
A: Treat the package as a credential exposure event, not just a dependency incident. Revoke and rotate every secret that the affected build environment could access, then inspect GitHub, CI runners, and secret manager logs for abnormal access, repository creation, and unexpected automation artefacts.
👉 Read our full editorial: Shai-Hulud 2.0 shows how npm supply chains expose cloud identity risk