Mini Shai-Hulud Is Back: npm Worm Hits over 160 Packages, including Mistral and Tanstack

What it is

"Mini Shai-Hulud," an npm supply-chain worm tracked by Aikido's Malware Team — 373 malicious package-version entries across 169 package names. This is the follow-up to their April SAP-targeted wave. The summary names the headline packages; the concrete cluster sizes are: @squawk (87 versions), @tanstack (83), @uipath (66), unscoped packages (39), @tallyui (30), @beproduct (18).

How it works

The compromised TanStack packages ship an obfuscated router_init.js at package root and declare an optional dependency pointing at a GitHub-hosted package:

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

That Git dependency carries a prepare script — bun run tanstack_runner.js && exit 1. npm runs lifecycle scripts for Git dependencies during install, so the payload executes even though nothing was "installed." Because the dependency is optional, the trailing exit 1 makes install fail after the code has run, so the failure looks like a benign optional-dep hiccup rather than a compromise. (Note: this differs from the SAP wave, which used a preinstall hook running setup.mjs → execution.js.)

What to do

The page's core detection step is grepping lockfiles and package caches for affected namespaces/packages:

@squawk/
@tanstack/
@uipath/
@tallyui/
@beproduct/nestjs-auth
@mistralai/
@draftauth/
@draftlab/
@taskflow-corp/cli
@tolka/cli
@ml-toolkit-ts/
@mesadev/
@dirigible-ai/sdk
@supersurkhet/

Plus unscoped names including safe-action, ts-dna, cross-stitch, cmux-agent-mcp, agentwork-cli, git-branch-selector, wot-api. The page notes the full list keeps moving and is appended to the blog.

The payload targets CI/CD and dev environments, hunting for: GitHub tokens, npm tokens, GitHub Actions OIDC tokens, AWS credentials + instance metadata, Kubernetes service-account files, HashiCorp Vault tokens and local Vault endpoints, env vars, and local filesystem secrets — so rotate any of these reachable from an affected build.

Caveats

The most important point for defenders: provenance is not a safety signal here. Trusted publishing lets a GitHub Actions workflow mint a short-lived npm token via OIDC. When attacker code runs inside that workflow, it uses the workflow's own OIDC permissions to publish — no long-lived token theft needed — and the result still carries valid provenance from the expected workflow. Provenance tells you where a package was built, not that the build was safe. This is the self-propagation engine: stolen access → repack → bump → republish.

flowchart TD
    A[Optional GitHub dep] --> B[prepare: bun run + exit 1]
    B --> C[Payload runs, install marked failed]
    C --> D[Steal npm/GitHub/OIDC/AWS/K8s/Vault]
    D --> E{Can victim publish?}
    E -->|OIDC in workflow| F[Mint token, repack, republish]
    F --> A
    E -->|No access| G[Exfil only]