Mini Shai-Hulud:
The npm Supply Chain Attack Explained

What Happened: The Mini Shai-Hulud Timeline

In late April 2026, a new variant of the Shai-Hulud supply chain worm appeared in the npm ecosystem. Security researchers quickly dubbed it "Mini Shai-Hulud" — a self-propagating worm that spread through npm's trusted package infrastructure, compromising developer credentials and publishing malicious versions of legitimate packages.

The attack unfolded in two waves. The first wave (late April) targeted the SAP developer ecosystem, compromising packages like @cap-js/sqlite, @cap-js/postgres, and mbt. The second wave (May 11–12) expanded dramatically: 373 malicious versions across 169 npm package names, including 42 @tanstack/* packages, the entire @mistralai SDK suite, @uipath automation tools, and packages in the @squawk and @tallyui namespaces.

StepSecurity detected the May 11th attack within 30 minutes. All affected package versions have been deprecated on npm and now display SECURITY warnings. But for developers and organizations that installed these packages during the window of exposure, the damage could be extensive: stolen credentials, compromised CI/CD pipelines, and unauthorized package publishing.

How the Attack Works: A Technical Breakdown

Mini Shai-Hulud executes a multi-stage attack chain that begins the moment a developer runs npm install. Understanding each stage helps you recognize the attack patterns and protect your own projects.

Stage 1: The Preinstall Hook

The attackers modified the package.json of legitimate packages, adding a preinstall script:

"scripts": {
  "preinstall": "node setup.mjs"
}

npm executes preinstall hooks before the package installation completes — meaning the malicious code runs automatically. The rest of the package source remains identical to the clean version, making casual code review ineffective. 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 downloads Bun v1.3.13 from GitHub releases, extracts the binary, and uses Bun to execute the main payload. Using Bun is strategic — it's a self-contained JavaScript runtime that doesn't depend on the local Node.js installation, allowing the malware to execute in environments where Node is constrained or unavailable.

Stage 3: Obfuscated Payload & Credential Theft

The execution.js file contains a single large obfuscated payload using a custom scrambler called ctf-scramble-v2. It checks for CI environments, avoids Russian-locale machines, and daemonizes itself to keep running after install completes.

The credential stealer targets a wide range of high-value assets:

• GitHub tokens and Actions secrets — including direct memory reads of CI runner processes
• npm access tokens — used to publish compromised versions of other packages
• Cloud credentials — AWS (STS, Secrets Manager), Azure (Key Vault), and GCP (Secret Manager)
• Kubernetes service account tokens
• Local config files — Claude/MCP configs, Azure/GCP token caches, VPN configurations

The GitHub Actions stealing path is sophisticated: an embedded Python helper scans /proc for the Runner.Worker process, reads its memory, and extracts masked secrets directly from the running CI worker — recovering secrets that GitHub would otherwise scrub from job logs.

Stage 4: Exfiltration via GitHub Dead-Drops

Mini Shai-Hulud uses GitHub itself as its exfiltration channel. After collecting credentials, it encrypts the results with AES-256-GCM (key wrapped by an embedded RSA public key) and commits the encrypted bundle to a public GitHub repository it creates using a stolen token. These repositories carry randomized Dune-themed names and the description "A Mini Shai-Hulud has Appeared".

The malware also scans GitHub commits for the keyword OhNoWhatsGoingOnWithGitHub, treating commit messages with the format OhNoWhatsGoingOnWithGitHub:<base64> as token dead-drops — decoding the base64 value into a GitHub token for further propagation.

Stage 5: Worm Propagation

Once Mini Shai-Hulud has valid tokens, it automatically propagates: it identifies npm packages the victim is authorized to publish, injects its payload into those packages, increments the patch version, and publishes the compromised release. It also attempts to push payload files into .vscode/ and .claude/ directories using stolen GitHub Actions tokens, committing with the message chore: update dependencies and the author claude.

Stage 6: The TanStack Delivery Route (May Wave)

The May 2026 wave introduced a more sophisticated entry path. Instead of an explicit preinstall hook, the malicious TanStack packages used an optional dependency pointing to a GitHub-hosted package:

"optionalDependencies": {
  "@tanstack/setup": "github:tanstack/router#79ac49..."
}

The Git dependency contains a prepare script that runs the payload. The trailing exit 1 causes npm to treat the optional dependency as failed — making the install output look less suspicious while the payload has already executed.

Affected Packages: What to Look For

If your project uses any package from these namespaces, check your lockfile immediately:

@tanstack/* @mistralai/* @uipath/* @squawk/* @tallyui/* @cap-js/* mbt

How to Check If Your Project Is Affected

Here's a step-by-step checklist to verify your project's safety:

• 1. Audit your lockfile — Check package-lock.json or yarn.lock for any package from the affected namespaces with publish dates around May 11–12, 2026.
• 2. Run npm audit — npm audit will flag deprecated versions with SECURITY warnings. Pay special attention to @tanstack/* and @mistralai/* packages.
• 3. Check GitHub Actions logs — Look for unexpected chore: update dependencies commits by the claude author, or any unusual package publishing activity.
• 4. Review your own packages — If you publish npm packages, check your publishing history for unauthorized version bumps that occurred around May 11–12.
• 5. Scan for indicator repositories — Check if any GitHub repositories with Dune-themed names and the description "A Mini Shai-Hulud has Appeared" were created under your organization's namespace.
• 6. Verify file integrity — Look for unexpected files in .vscode/ (tasks.json, setup.mjs) or .claude/ (execution.js, setup.mjs) directories.

How to Protect Your Frontend Projects

Supply chain attacks aren't going away. Here's a practical defense strategy that every development team should implement:

1. Lock Down Your Dependencies

• Pin exact versions — Never use ^ or ~ in production dependencies unless you control the package
• Use lockfile integrity — Run npm ci instead of npm install in CI/CD to enforce exact lockfile resolution
• Commit your lockfile — Always track package-lock.json or yarn.lock in version control

2. Audit Lifecycle Scripts

• Install with scripts disabled — Run npm install --ignore-scripts first, audit the code, then run scripts manually
• Review preinstall/postinstall hooks — Any package with a preinstall script should trigger extra scrutiny
• Use npm audit regularly — Set up a pre-commit hook or CI step that runs npm audit --audit-level=high

3. Harden Your Credentials

• Enable 2FA on npm — Both for login and publishing. This is now mandatory for high-download packages
• Use granular tokens — Generate npm tokens with minimal scopes. Don't use your personal token in CI/CD
• Separate CI/CD secrets — Use different tokens for different environments. Rotate them regularly

4. Automate Security Scanning

• npm audit in CI — Fail the build on high/critical advisories
• Dependency scanning tools — Consider Socket.dev, Snyk, or GitHub Dependabot for automated alerts
• Monitor install scripts — Use --ignore-scripts in CI, then selectively enable for trusted packages
• Private registry mirroring — For critical projects, use Verdaccio or a similar proxy to cache and audit packages before they reach developers

What This Means for Business Owners

If you're hiring a web developer or agency to build your website, supply chain security is now part of the conversation. Mini Shai-Hulud shows that a single compromised dependency can expose your entire project — and potentially your infrastructure credentials — to attackers.

Here's what to look for in a developer or team:

• They pin dependencies. A good developer doesn't leave version ranges floating. They commit lockfiles and know exactly what's in their dependency tree.
• They use npm audit. Regular security auditing should be part of their workflow, not an afterthought.
• They follow security news. They were aware of Mini Shai-Hulud within days (or hours) of the disclosure and took action if needed.
• They use 2FA everywhere. npm, GitHub, cloud providers — all accounts behind two-factor authentication.
• They don't take shortcuts with CI/CD. Properly scoped tokens, no hardcoded secrets, and automated security scanning in the pipeline.

The npm ecosystem is the backbone of modern frontend development. Trust in it is earned through vigilance — and that vigilance should be part of your developer's professional practice. When I build web applications for clients, dependency security and regular npm audits are baked into the development process from day one.

FAQ

Stay Secure — Build Smart

Mini Shai-Hulud is a wake-up call for the entire frontend ecosystem. Supply chain attacks are not theoretical — they're happening now, and they're getting more sophisticated. The good news: the defense tools exist, and they're mostly free.

If you're building a web application and want a developer who treats security as a first-class concern — not an afterthought — reach out to me. I'm a full-stack developer with 20+ years of experience, and I build every project with dependency security baked in from day one: npm audit in CI, pinned versions, 2FA everywhere, and regular lockfile reviews.