Would your org have caught the Shai-Hulud npm worm? A checklist

Shai-Hulud was a self-replicating npm worm that stole developer credentials and used them to publish more compromised packages. Your org would likely have caught it if you pinned dependencies, kept tokens short-lived, required phishing-resistant MFA and watched outbound traffic. This checklist lets you test each of those honestly.

What happened, briefly?

CISA published an alert on 23 September 2025 about a supply chain compromise affecting npm. It described over 500 compromised packages. The malware authenticated to the npm registry as a compromised developer, injected code into other packages and published new compromised versions. It also searched the environment for GitHub personal access tokens and API keys for AWS, Google Cloud and Microsoft Azure, then sent them to an attacker-controlled endpoint and to a public GitHub repository named "Shai-Hulud."

OWASP's 2025 Top 10 uses the incident as an example too: post-install scripts harvested data, npm tokens found on victim machines were used to publish malicious versions of other packages, and it reached over 500 package versions before npm disrupted it.

Nobody was careless for being a victim. Developers install packages all day. The question is what limited the blast radius.

The checklist

Answer each line yes, no or unsure. Unsure is a no until you check.

Before install

• Do you commit lockfiles and install from them in CI?
• Can you list every build that pulled a package version published in a given window?
• Do you delay adopting brand-new versions of packages, or review them first?
• Do you run an install-time check for known-malicious packages?

On the developer machine

• Are npm and GitHub tokens short-lived, scoped and kept out of plain files and environment variables?
• Does every developer account use phishing-resistant MFA, as CISA recommends for GitHub and npm?
• Are install scripts restricted where your package manager allows it?

In the pipeline

• Are CI secrets limited to the jobs that need them?
• Do you publish from CI with tightly scoped credentials, not from laptops?
• Do you alert when a package your org owns publishes a version nobody on the team released?

Detection and response

• Can you search artifact repositories and caches for affected versions? CISA says to check them.
• Can you rotate every developer credential within hours, and do you know who owns that?
• Do firewall logs let you look for connections to suspicious domains? CISA specifically named webhook.site domains.
• Do you audit GitHub Apps, OAuth apps, webhooks and repository secrets, and remove what is unnecessary?

How do you read your score?

Count the "no" answers by group. The cluster matters more than the total. Many nos in "on the developer machine" mean a single infected laptop could expose cloud keys. Many nos in "detection" mean you would find out late.

A common honest result: good lockfile habits, weak token hygiene. Fix tokens first. A stolen long-lived token is what let this worm publish as a real maintainer.

What can tooling cover?

Tooling can cover part of this. A lockfile and SBOM inventory answers "which builds used that version." Secret scanning finds credentials left in repositories. An install-time check can flag known-malicious packages. Safeguard's Package Firewall, for instance, is documented as an install-time proxy for npm and pip that checks typosquats, namespace confusion and known-malicious signatures, with an audit mode that records decisions without blocking. None of that replaces short-lived credentials or MFA.

What to do

1. Run the checklist with one engineer and one platform owner in the room.
2. Rotate any long-lived npm and GitHub tokens now, and replace them with scoped, short-lived ones.
3. Enforce phishing-resistant MFA on npm and GitHub accounts.
4. Make sure you can answer "which builds used package X at version Y" in under an hour.
5. Write down who rotates credentials and how, before you need it.

Quick check

Sources

• CISA, Widespread Supply Chain Compromise Impacting npm Ecosystem (23 September 2025)
• OWASP Top 10 2025, A03 Software Supply Chain Failures
• Safeguard docs, Package Firewall

Last reviewed: 18 October 2026.