npm Worm Hit Your Supply Chain? Rotate, Revoke, and Contain Before It Spreads

Key Takeaways

• Act in the first hour, not the first day. Worms spread faster than your average on-call rotation.
• Rotate before you investigate. Waiting to “understand the blast radius” means the blast radius keeps growing.
• Your CI/CD tokens are the real target. npm tokens get rotated. Pipeline tokens become full org takeover.

It starts with a postinstall script. Something in your dependency tree quietly writes a cron job, grabs a GitHub token, and pushes to a private repo. Within hours, every developer on your team pulls the poisoned package. By morning, the worm has replicated across your internal packages, your CI runners, and possibly your production secrets.

This is not theoretical. The Shai-Hulud-style worm pattern has shown up in the wild, and when it does, it moves faster than most incident response teams can react. The difference between a contained blast and a boardroom apology call usually comes down to the first 60 minutes.

Phase 1: Stop the Bleeding (0-60 Minutes)

When you detect self-replicating behavior in your npm supply chain, do not waste time gathering evidence first. Evidence is important, but a live worm does not care about your forensic process. It cares about how many machines it can infect.

Immediate Actions (First 15 Minutes)

1. Isolate the affected registry. If your internal npm registry (Verdaccio, Artifactory, npm Enterprise) is showing the malicious package, take it offline immediately. Do not delete it yet. You will need it for analysis. Just stop serving it.
2. Revoke the npm token associated with the package. Go to your npm account settings right now. Revoke the token that published the poisoned package. If the attacker published under a compromised maintainer account, revoke that account's tokens entirely.
3. Quarantine CI/CD runners. Any runner that successfully executed npm install with the bad package is potentially compromised. Pull it offline from your orchestration layer. Do not reboot yet. Memory forensics matter.
4. Freeze npm installs in your pipelines. Update your CI configuration to block all installs from the affected registry until you verify the cached packages are clean.

I have seen teams spend 45 minutes in a war room debating whether the package is actually malicious. The worm was already in three production systems by the time they reached consensus. Assume the worst when you see self-replication patterns.

Containment (15-60 Minutes)

Once you have stopped the active spread, you need to understand scope. This is where most teams stall because they are trying to be thorough instead of being fast.

• Check your audit logs. Look for packages published in the last 24-48 hours that match the malicious pattern. Search for postinstall, preinstall, and shell execution in package.json scripts.
• Scan all node_modules across your repositories. Use a script to grep for suspicious patterns: DNS exfiltration domains, base64-encoded payloads, unexpected child_process calls.
• Identify all runner instances that have executed the compromised package. This includes your GitHub Actions runners, GitLab runners, Jenkins agents, and any self-hosted CI nodes.

The goal here is not perfection. It is stopping the worm from gaining more access while you prepare for the full remediation.

Phase 2: Full Containment and Token Rotation (Hours 1-6)

This is where most organizations fail. They rotate npm tokens and call it a day. But the worm does not just use npm tokens. It leverages your CI/CD pipeline tokens to spread further, creating secondary infection vectors that look legitimate.

Token Rotation Checklist

Rotate every credential that could have been exposed through the compromised package:

• npm access tokens. All personal access tokens on the compromised publisher account. All project-scoped tokens.
• GitHub personal access tokens. Any token that the CI runner had access to. This includes fine-grained PATs and classic PATs.
• CI/CD pipeline tokens. Service account tokens in GitHub Actions, GitLab CI, Jenkins credentials. These are the highest-value targets because they often have broad repository access.
• AWS, GCP, and Azure credentials. If the worm had access to runner environments with cloud credentials, rotate everything in those environments. The worm could have written a new IAM role or service account.
• Docker Hub and container registry credentials. The worm may have pushed malicious container images to use as a distribution mechanism.
• Internal package registry tokens. If you run Verdaccio or Artifactory, revoke and regenerate all tokens.

Important: Rotate in this order. If you rotate npm tokens first, the attacker might still have CI tokens and can re-publish under a different package. Lock down the distribution channels before you change the authentication.

System Rebuilding Strategy

Do not trust any system that executed the compromised package. Rebuild your CI runners from golden images. Rotate SSH keys. Reinstall development machines if they had direct access to the affected registry.

If you must keep a system running for forensic analysis, isolate it on a separate network segment and do not allow it to access your production environments. Preserve the volatile state. Take a memory dump before any reboots.

Phase 3: Detection and Hunt (Hours 6-24)

After containment, you need to answer the question that keeps CISOs awake: what did the worm actually do?

Log Analysis Focus Areas

• npm audit logs. Look for packages downloaded by your CI runners after the initial compromise. The worm may have installed additional tooling under a different name.
• Git push events. Check for unauthorized commits to your repositories, especially to .github/workflows or CI configuration files. Attackers often modify pipelines to create persistent access.
• Network egress logs. Search for DNS queries to unusual domains, connections to unknown IP ranges, or large outbound data transfers from your CI infrastructure.
• Kubernetes pod logs. If you run containerized workloads, check for new cron jobs, modified deployment manifests, or unexpected sidecar containers.

What to Look For in Package Sources

When reviewing the malicious package, look for these patterns that indicate worm behavior:

• Obfuscated shell commands. Base64 decoding, eval(), exec() with string concatenation.
• Environment reconnaissance. Code that gathers hostname, IP addresses, environment variables, mounted volumes.
• Self-replication logic. Package.json scripts that modify other packages in node_modules or update lockfiles.
• Persistence mechanisms. Cron jobs, systemd services, SSH authorized_keys, or modified shell profiles.
• Data exfiltration. HTTP POST requests to external endpoints with environment variable dumps or git credential theft.

If you find any of these, assume the worm has full visibility into your CI/CD environment. Rotate your secrets again after the hunt, because some may have been captured after your initial rotation.

Phase 4: Communication and Recovery (Hours 24-48)

By this point, the immediate threat should be contained. But the organizational response is just beginning. Stakeholders need answers, and your security posture needs to change.

Stakeholder Communication

Different audiences need different information. Your engineering lead needs the technical timeline. Your CISO needs the business impact. Your board needs the risk assessment and remediation plan.

• Technical teams: Share the IOCs (Indicators of Compromise), affected package versions, and remediation steps.
• Leadership: Focus on business impact, data exposure risk, and remediation timeline. Avoid technical jargon.
• Customers: If customer data was potentially exposed, prepare a transparent notification. Do not disclose technical details that could help other attackers.

Recovery Actions

1. Restore CI/CD pipelines from known-good configurations. If the worm modified your workflow files, do not trust the current versions.
2. Update dependency pins. Lock all npm packages to specific versions with integrity checksums.
3. Implement package allowlisting. Use tools like npm's audit feature, Snyk, or GitHub Dependabot to monitor for malicious packages.
4. Add preinstall/postinstall hook scanning. Block or flag any package that runs scripts during installation.

Prevention: Building Worm-Resistant Supply Chains

The real win is making sure this cannot happen again. Here are the controls that actually matter:

Registry-Level Protections

• Private registry with access controls. Use an internal npm registry that requires authentication for all publishes and installs. Block direct access to the public registry for production workloads.
• Package integrity verification. Enable checksum verification on all installs. Use npm audit in CI pipelines.
• Publish authorization. Require multi-person approval for package publishes to critical dependencies.

CI/CD Hardening

• Runner isolation. Use ephemeral runners that are destroyed after each job. Never cache node_modules between jobs.
• Token scoping. Use the principle of least privilege for all CI tokens. A GitHub Actions token should only access the repository it is running in.
• Network segmentation. CI runners should not have outbound internet access unless explicitly required.

Monitoring and Detection

• Alert on anomalous package installs. Watch for packages with high download counts that have unusual script patterns.
• Network flow monitoring. Detect outbound connections from build runners that do not match expected patterns.
• File integrity monitoring. Track changes to package.json and lockfiles in your repositories.

Common Mistakes That Make Worms Worse

Based on incident response patterns I have seen, these mistakes consistently make supply chain worms harder to contain:

• Investigating before containing. Spending hours analyzing the worm while it continues to spread.
• Rotating the wrong tokens. Changing npm tokens but leaving CI/CD service tokens active.
• Reusing compromised infrastructure. Rebooting a runner instead of rebuilding it from a clean image.
• Ignoring the lockfile. Not updating package-lock.json after rotation, leaving downstream systems vulnerable.
• Delaying communication. Waiting for 100% certainty before notifying stakeholders. By then, the damage is already public.

When to Escalate

Not every npm incident requires a full war room. But these signals mean you should escalate immediately:

• Self-replicating behavior detected. Any package that modifies other packages or spreads beyond its own installation.
• CI/CD token compromise. Evidence that pipeline credentials have been used to access other repositories.
• Production system exposure. The worm reached systems that handle sensitive data or customer information.
• Multiple affected packages. More than one package in your dependency tree shows malicious behavior.

When in doubt, escalate. The cost of over-responding is always less than the cost of under-responding to a self-replicating threat.

Related Resources

If this worm containment guide was helpful, you might also want to check out these related articles:

• Attackers Don't Hack Your Repo. They Read Your .npmrc – Learn how attackers extract credentials from your local npm configuration.
• Your npm install Is Silently Executing Malware Right Now – Understand why SAST tools miss install-time attacks.
• Your Allowlist Is Blind to These 1-Character Typosquats – Discover how typosquatting attacks bypass your security controls.

FAQ

How fast does an npm worm spread?

Typically within hours. A self-replicating npm package can infect every developer machine and CI runner that runs npm install. If your CI pipeline runs builds continuously, the worm can propagate across your entire infrastructure before you detect it.

What is the first thing I should do when I detect a malicious npm package?

Isolate your npm registry and revoke the publishing token. Do not spend time analyzing the package while it is still being distributed. Containment first, investigation second.

Should I rotate my GitHub tokens if a malicious npm package was installed on my CI runner?

Yes. Any token that was accessible to a compromised runner should be considered exposed. The worm could have exfiltrated it during the installation process. Rotate all tokens that the runner had access to, not just the ones you think were used.

How do I prevent npm worms from reaching my production systems?

Use an internal registry with strict access controls, require multi-person approval for package publishes, scan all packages for malicious scripts before installation, and use ephemeral CI runners that are rebuilt from clean images.