TL;DR: A new Shai-Hulud campaign is spreading through npm preinstall hooks, with OXSecurity reporting more than 444 compromised packages and over 2 billion monthly downloads affected, while the malware steals GitHub tokens, cloud credentials, and persists through developer tools. Package governance now has to assume install-time code execution is an identity and secrets problem, not just a supply chain hygiene issue.
NHIMG editorial — based on content published by OXSecurity: Keyv and Cacheable are affected with +440 Packages Compromised and Over 2B Monthly Downloads
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 package supply chain attacks create NHI risk?
A: Because the attacker usually wants the non-human credentials behind the build and release process, not just the infected package.
Q: How do security teams know if exposed secrets are becoming a real risk?
A: The clearest signal is whether the secret can still authenticate and whether it can reach high-value actions after login.
Practitioner guidance
- Lock down lifecycle scripts in package installs Disable or tightly restrict preinstall and postinstall execution for packages that are not explicitly trusted.
- Rotate and scope developer and CI tokens Treat GitHub tokens, cloud keys, and package-publish credentials as non-human identities with short lifetimes and minimal scopes.
- Search for infected repositories and secret reuse Hunt for the IOC string in repositories, package histories, and developer machines, then verify whether stolen secrets were reused across repos or CI jobs.
What's in the full analysis
OXSecurity's full article covers the operational detail this post intentionally leaves for the source:
- The complete indicator list, including the package names and version ranges that are currently affected.
- The malware strings, filenames, and repository markers that teams can use for internal hunting and triage.
- The install-time execution chain from preinstall script to credential theft, persistence, and self-spread.
- The full recommended response sequence for developers and platform teams managing compromised repositories.
👉 Read OXSecurity's analysis of the Shai-Hulud npm supply chain campaign →
Shai-Hulud in npm: are package controls keeping up?
Explore further
Package install time is now an identity event. When a dependency can execute code during installation, the trust decision is not just about code provenance. It is also about which secrets, tokens, and repository permissions the installer can reach. That makes package managers part of the identity control plane, especially where CI agents and developer workstations hold reusable credentials. Practitioners should treat install-time execution as a governed access path, not a benign build step.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
- 91.6% of secrets remain valid five days after the targeted organisation is notified, according to Ultimate Guide to NHIs.
A question worth separating out:
Q: Who is accountable when a supply chain package compromise reaches developer systems?
A: Accountability typically spans the engineering team that approved the dependency path, the platform team that defined install policy, and the security function that set provenance and monitoring requirements. Frameworks such as NIST CSF and MITRE ATT&CK help assign responsibility across prevention, detection, and response.
👉 Read our full editorial: Shai-Hulud’s npm resurgence exposes weak package governance