Mini Shai-Hulud: The npm Supply Chain Worm Explained

Supply chain attacks against open source registries have become one of the most persistent threats facing modern software development. Following the original Shai-Hulud worm that swept through npm in 2025, a new variant called Mini Shai-Hulud emerged in April 2026, first targeting the SAP developer ecosystem before expanding into a much larger campaign that compromised over 160 packages by May 2026.

Mini Shai-Hulud is a worm designed to live inside modern build systems, harvest tokens from CI/CD pipelines and developer workstations, and then weaponize that access to publish malicious versions of additional packages. The attack abuses npm lifecycle scripts, the Bun JavaScript runtime, GitHub trusted publishing workflows, and OIDC authentication to spread automatically through trusted release paths.

In this blog, we explain how the Mini Shai-Hulud worm works in technical detail and how organizations can defend themselves against this supply chain attack.

Simulate Supply Chain Attacks with 14-Day Free Trial of Picus Platform

Mini Shai-Hulud npm Worm Explained

What is npm?

npm, short for Node Package Manager, is the default package registry for the Node.js JavaScript runtime and the largest software registry in the world. Developers use npm to install, share, and manage reusable code libraries through a simple command line interface. The npm ecosystem powers a huge portion of modern web, mobile, and server-side development. Front-end frameworks like React and Vue, back-end runtimes like Express, build tools, database drivers, authentication libraries, and enterprise SDKs all flow through npm. A single application can easily pull in hundreds or even thousands of transitive dependencies during installation.

This depth of dependency trust is precisely what makes npm such an attractive target for attackers. When a malicious version of a popular package is published, every project that installs or updates that dependency executes the attacker's code, often inside privileged environments such as developer laptops with access to source code, or CI/CD runners holding production deployment credentials.

Mini Shai-Hulud Targeting the SAP Developer Ecosystem

Mini Shai-Hulud first appeared in late April 2026 as a large-scale npm supply chain attack targeting the SAP developer ecosystem. The first known wave compromised four trusted packages used in SAP development workflows: @cap-js/sqlite version 2.2.2, @cap-js/postgres version 2.2.2, @cap-js/db-service version 2.10.1, and mbt version 1.2.48. Because these packages were already trusted and widely used, the malicious code spread directly through normal software installation processes.

The attack worked by adding a preinstall hook to otherwise legitimate packages. Once installed, the malware downloaded and executed a second-stage payload designed to steal credentials and spread further. The malware targeted GitHub tokens, npm credentials, GitHub Actions secrets, and cloud credentials from providers such as AWS, Azure, and Google Cloud. Stolen data was then uploaded to attacker-controlled GitHub repositories. Each repository created by the worm carries a hardcoded description that became the campaign's signature.

By May 2026, the campaign had expanded far beyond SAP-related packages. Security researchers identified 373 malicious package versions across 169 npm package names [1]. The affected namespaces included popular ecosystems such as @tanstack, @uipath, @squawk, and @tallyui, along with several standalone packages. The largest clusters were linked to @squawk, @tanstack, @uipath, and @tallyui.

Organizations that installed affected versions should treat the impacted developer machine or CI/CD runner as compromised. Recommended response actions include rotating npm tokens, GitHub credentials, GitHub Actions secrets, and cloud credentials across AWS, Azure, and GCP. Security teams should also review recent package publishing activity and CI/CD workflows for signs of unauthorized access or suspicious publishing behavior.

How Mini Shai-Hulud Worm Attack Works

Mini Shai-Hulud executes a multi-stage attack chain that begins the moment a developer or build agent installs a compromised package. Understanding each stage helps defenders identify telltale signals across both endpoints and CI/CD systems.

Stage 1: npm Lifecycle Script Execution

In the original SAP wave, the attackers modified the package.json of legitimate packages to add a preinstall hook [2].

Because npm runs preinstall hooks before the installation of the package even completes, the malicious code executes automatically the moment a developer or CI runner invokes npm install. The rest of the package source remains byte-for-byte identical to the previous clean version, so casual code review does not reveal the compromise. Only the install hook and two added files, setup.mjs and execution.js, differ from the legitimate release.

Stage 2: Bun Bootstrapper

The setup.mjs file is a small loader that inspects the operating system and architecture, downloads Bun version 1.3.13 from a GitHub release if it is not already present, extracts the binary, and uses Bun to run execution.js. The use of Bun is significant because it provides a self-contained JavaScript runtime that does not depend on the local Node.js installation and can execute the obfuscated payload in environments where Node would otherwise be constrained.

Stage 3: Obfuscated Payload Execution

The execution.js file is a single large obfuscated payload that uses a custom string scrambling layer labeled ctf-scramble-v2. It checks whether it is running in a CI environment, exits if it detects Russian locale settings, and daemonizes itself on non-CI machines so it can keep running after the install completes. The payload then begins enumerating secrets from both developer laptops and CI/CD runners.

The credential stealer targets a long list of high-value assets. It collects GitHub tokens, GitHub Actions secrets, AWS STS identity along with Secrets Manager and SSM parameters, Azure subscription information along with Key Vault names and secret values, GCP project identity and Secret Manager values, Kubernetes service account tokens, and a wide range of local files including Claude config, MCP config, GCP token databases, Azure token caches, Signal config, Electrum wallets, and VPN configuration files.

The GitHub Actions stealing path is particularly noteworthy. The payload includes an embedded Python helper that scans /proc for the Runner.Worker process, reads its memory, and extracts masked secret structures directly from the running CI worker. This allows the malware to recover secrets that GitHub Actions would otherwise scrub from job logs.

Stage 4: GitHub-based Exfiltration and Dead-drop

Mini Shai-Hulud uses GitHub itself as its exfiltration channel. After collecting credentials, the malware compresses and encrypts the results using AES-256-GCM with the AES key wrapped by an embedded RSA public key, then commits the encrypted bundle as a JSON file under the path results/results-<timestamp>-<counter>.json in a public GitHub repository it creates using a stolen token. The repository is given a randomized Dune-themed name and the hardcoded description "A Mini Shai-Hulud has Appeared."

The malware also searches GitHub commits for the propagation keyword OhNoWhatsGoingOnWithGitHub, treating any commit message of the form OhNoWhatsGoingOnWithGitHub:<base64> as a token dead-drop, decoding the base64 value into a GitHub token, and testing it for repository access.

Stage 5: Propagation through Release Workflows

Mini Shai-Hulud is built to spread. Once it has tokens, it looks for npm packages the victim is authorized to publish, modifies those package tarballs by copying the current payload into execution.js, writes a fresh setup.mjs, sets the scripts.preinstall field to node setup.mjs, increments the patch version, repacks the tarball, and publishes the new compromised release.

In analyzed SAP samples, the malware also attempted to push files into .vscode/tasks.json, .vscode/setup.mjs, .claude/execution.js, .claude/setup.mjs, and .claude/settings.json using stolen GitHub Actions tokens. The commits used the message chore: update dependencies with the author claude claude@users.noreply.github.com, which is one of the more reliable indicators of compromise.

Stage 6: The New TanStack Delivery Route

The May 2026 wave introduced a more sophisticated entry path. Instead of an explicit preinstall hook on the compromised package, the malicious TanStack packages added an optional dependency that points to a GitHub-hosted package.

That Git dependency contains a prepare script that runs bun run tanstack_runner.js && exit 1. Because npm runs lifecycle scripts for Git dependencies during installation, the malicious code executes through the optional dependency.

The trailing exit 1 causes npm to treat the optional dependency as failed, which makes the install output look less suspicious because npm tolerates optional dependency failures. The payload, however, has already run.

What Defenders Should Look for Against Mini-Shai Hulud Worm?

Defenders should focus on identifying signs of unexpected package behavior and suspicious publishing activity. Security teams should review environments for recently installed packages tied to affected namespaces such as @tanstack, @uipath, @squawk, @tallyui, and the earlier SAP-related packages, including @cap-js/sqlite, @cap-js/postgres, @cap-js/db-service, and mbt.

Teams should also investigate CI/CD logs for unusual activity during package installation, especially unexpected script execution, suspicious outbound connections, failed optional dependency installs, or publishing actions triggered by workflows that normally do not publish packages. Any unexpected creation of GitHub repositories or unusual token usage should be treated as a high-priority signal.

If affected versions were installed, organizations should assume the impacted developer workstation or CI/CD runner may be compromised. Recommended response actions include rotating npm tokens, GitHub credentials, GitHub Actions secrets, and cloud credentials across AWS, Azure, and Google Cloud. Security teams should also audit recent package publishing history, GitHub Actions activity, and repository changes for signs of unauthorized access or tampering.

How Picus Helps Simulate Mini Shai-Hulud Attacks?

We also strongly suggest simulating the Mini Shai-Hulud malware attacks to test the effectiveness of your security controls against sophisticated cyber attacks using the Picus Security Validation Platform. You can also test your defenses against other supply chain attacks, such as SmoothOperator, XZ Utils, and JetBrains TeamCity, within minutes with a 14-day free trial of the Picus Platform.

Picus Threat Library includes the following threats for the Mini Shai-Hulud malware attacks:

Picus also provides actionable mitigation content. Picus Mitigation Library includes prevention signatures to address Mini Shai-Hulud malware attacks in preventive security controls. Currently, Picus Labs has validated the following signatures for Mini Shai-Hulud malware:

Start simulating emerging threats today and get actionable mitigation insights with a  14-day free trial  of the Picus Security Validation Platform.

References

[1] R. Silva, "Mini Shai-Hulud Is Back: npm Worm Hits over 160 Packages, including Mistral and Tanstack," May 12, 2026. Available: https://www.aikido.dev/blog/mini-shai-hulud-is-back-tanstack-compromised

[2] R. Silva, "Mini Shai-Hulud Targets SAP npm Packages With a Bun-Based Secret Stealer," Apr. 29, 2026. Available: https://www.aikido.dev/blog/mini-shai-hulud-has-appeared