Shai-Hulud npm Attack: How AI Spots Supply Chain Worms

A supply chain attack that quietly steals cloud credentials is bad enough. Shai-Hulud 2.0 adds something nastier: it can run before your dependency even “installs,” and if it can’t steal what it wants, it may try to wipe a developer’s home directory.

Unit 42’s November 2025 update describes a renewed campaign affecting tens of thousands of GitHub repositories, including 25,000+ malicious repositories across ~350 unique users. That scale matters because npm isn’t just “open source.” It’s your build system, your CI/CD pipeline, and often your path into production.

This is where the “AI in cybersecurity” conversation gets real. Most teams still treat npm supply chain security like a checklist: run an audit, pin versions, hope nothing weird happens. Shai-Hulud is built to slip past that mindset. The better approach is continuous, behavioral monitoring—exactly the kind of thing AI is good at when you use it with discipline.

What made Shai-Hulud 2.0 spread so fast

Shai-Hulud scaled because it targeted trust relationships developers rely on daily—npm tokens, GitHub access, and automated publishing rights. A worm doesn’t need a long dwell time if it can replicate through your organization’s software lifecycle.

The original Shai-Hulud campaign (investigated in September 2025) executed through a post-install script and focused on credential harvesting and automated propagation. The November wave changed the playbook:

Pre-install execution: the “hits every pipeline” trick

Pre-install execution widens impact dramatically because it triggers earlier in the dependency lifecycle. In practical terms, it increases the chance that:

• It runs on ephemeral CI runners (where secrets often live in environment variables)
• It runs in container builds (where tokens get injected during build steps)
• It runs even when downstream build steps are locked down

If your security controls assume malicious behavior will show up later—during test, during packaging, during runtime—this is a timing attack on your assumptions.

Aggressive fallback: from theft to disruption

Shai-Hulud 2.0 includes a fallback mechanism that attempts to destroy the user’s home directory if it can’t successfully steal credentials or establish exfiltration/persistence. That’s a big escalation: it turns a supply chain compromise into a potential CI/CD denial-of-service event.

Here’s the uncomfortable truth: many orgs are prepared for data theft and credential rotation. Far fewer are prepared for a sudden wave of developer workstation damage and broken pipelines right before a release freeze.

(And yes—December release pressure is real. Between end-of-year production changes, shorter staffing windows, and “ship it before holidays” deadlines, pipeline disruption in late Q4 can cost weeks.)

How the worm works (and why traditional controls miss it)

Shai-Hulud’s core strength is automation: steal secrets, then use those secrets to publish more compromised packages. It chains developer tooling together like dominoes.

Based on the incident details, the worm hunts for:

• .npmrc files (npm tokens)
• Environment variables and config files for GitHub Personal Access Tokens (PATs)
• Cloud credentials and API keys for AWS, Azure, and GCP

Then it does something that should make every security lead flinch: it creates a public GitHub repo under the victim’s account and commits the stolen secrets to it. That instantly turns a private compromise into public exposure.

Persistence through developer platforms

The November campaign goes further by attempting persistence via a GitHub Actions workflow file (notably described as discussion.yaml). The concept is straightforward and brutal:

• Register the infected machine as a self-hosted runner
• Use GitHub discussions as a control channel
• Execute arbitrary commands without needing traditional C2 infrastructure

That’s a recurring theme in modern attacks: adversaries hide in your legitimate SaaS automation fabric because the traffic looks “normal” at first glance.

The AI angle attackers already understand

Unit 42 assessed with moderate confidence that an LLM was used to help generate parts of the malicious bash scripting (based on telltale artifacts like comments and emojis). You don’t need to overhype this. The key point is simpler:

Attackers are using generative AI to produce serviceable malware faster and at higher volume.

So defenders need to respond with systems that don’t rely on “someone noticing” a suspicious diff in a dependency.

Where AI actually helps: detecting npm supply chain compromises early

AI helps most when it’s aimed at the behaviors that humans and static scanners consistently miss: timing anomalies, relationship anomalies, and ecosystem anomalies. Shai-Hulud is a perfect example because it’s not just malicious code—it’s malicious activity across systems.

1) Ecosystem anomaly detection (registry + GitHub signals)

A practical AI model for npm supply chain defense doesn’t need to “understand JavaScript.” It needs to understand what normal looks like for:

• Maintainer publishing cadence (frequency, time-of-day, burst patterns)
• Package versioning behavior (unusual patch jumps, odd tag usage)
• Dependency graph changes (sudden new preinstall scripts, new binary fetches)
• Cross-account patterns (many new repos created with similar descriptions)

Shai-Hulud 2.0’s signature behavior—credential exfiltration to public GitHub repos described as “Sha1-Hulud: The Second Coming.”—is exactly the kind of repeated pattern AI should flag quickly.

If you’re only scanning the artifact after it lands in your lockfile, you’re late.

2) CI/CD behavioral monitoring (where pre-install hits)

Pre-install execution is a reminder that CI/CD telemetry is security telemetry.

AI-driven monitoring can flag:

• Build steps that suddenly spawn detached background processes
• Outlier network destinations during dependency installation
• New file writes for suspicious payload names (like setup_bun.js or bun_environment.js)
• Unexpected Git operations from build agents (creating repos, committing secrets)

This is where I’ve found teams get the most value: treat the pipeline like a production environment with detections, not like a disposable utility.

3) Secrets exposure detection that’s fast enough to matter

Many orgs run secret scanning “eventually.” Shai-Hulud turns “eventually” into “already public.”

AI-assisted secret detection works best when it’s:

• Continuous (every PR, every push, every workflow change)
• Context-aware (recognize token formats + usage patterns)
• Automated in response (open incident, revoke token, block publish)

The goal isn’t just finding secrets—it’s shortening the window between exposure and revocation to minutes.

A pragmatic response plan for security and engineering leaders

If you suspect exposure, assume any secret on developer machines and CI agents is compromised and act immediately. Shai-Hulud is designed to turn a single compromised maintainer into many compromised packages.

Step 1: Rotate credentials like you mean it

Rotate:

• npm access tokens
• GitHub PATs
• SSH keys
• Cloud access keys (AWS/GCP/Azure)
• Third-party API keys used in CI/CD

Also invalidate old tokens, not just issue new ones. Teams sometimes forget that “rotation” without revocation leaves the old door open.

Step 2: Audit dependencies with lockfile discipline

Run dependency audits, but focus on what actually gets deployed:

• Review package-lock.json, yarn.lock, or pnpm-lock.yaml for compromised versions
• Remove or update affected packages immediately
• Investigate any dependency that added or modified preinstall/postinstall scripts

A good internal standard: builds should fail if lockfiles are missing or changed outside approved workflows.

Step 3: Review developer platform integrity (GitHub + Actions)

Have developers check for:

• Unknown public repositories (especially ones created recently)
• Suspicious commits or unexpected workflow files
• Signs of self-hosted runner registration they didn’t initiate

And if you’re a security lead: don’t make this a “developer scavenger hunt.” Centralize detection where possible.

Step 4: Put guardrails on publishing rights

This is where prevention beats cleanup:

• Require MFA for npm and GitHub
• Use least-privilege tokens (scoped, short-lived where supported)
• Separate “build” identities from “publish” identities
• Require approval gates for publishing critical packages

One stance I’ll defend: a single developer workstation should not be able to publish production-impacting packages without a second control. That’s not bureaucracy; that’s reality-based security.

People also ask: what should we monitor right now?

Monitor for evidence of pre-install payloads, unusual webhook traffic, and GitHub workflow persistence. Even if you don’t have the exact indicators, the behaviors are distinct.

Focus your detection efforts on:

• Unexpected outbound connections during dependency install (especially to generic collection endpoints)
• File artifacts matching suspicious payload naming conventions
• Workflow files appearing in repos that don’t normally use GitHub Actions
• Any repo creation bursts across developer accounts

If you already run endpoint and network telemetry, prioritize coverage on macOS and Linux developer hosts and on CI runners. That’s where npm installs happen at scale.

Turning this incident into a lasting advantage

The Shai-Hulud npm supply chain attack is a reminder that attackers don’t need to beat your runtime defenses if they can beat your build reality. Pre-install execution, automated propagation, and SaaS-based persistence are a combination built for scale.

AI is your best line of defense here—but only if you aim it at the right places: package ecosystem behavior, CI/CD execution behavior, and secrets exposure response time. Static scanning still matters, but it’s not enough when the attack is designed to execute earlier than your scanners and spread faster than your reviews.

If you want one operational goal to carry into 2026, make it this: reduce the time between “a dependency behaves strangely” and “publishing and secrets are automatically contained” to under an hour. What would it take in your environment to get that down to 15 minutes?