Skip to content
Supply ChainnpmCI/CDcredential-theftCVE

Mini Shai-Hulud: The npm Worm That Reached CISA's KEV Catalog

4 min read
Share

Mini Shai-Hulud: The npm worm that made it into CISA's KEV catalog

On May 11, 2026, at 19:20 UTC, someone started pushing malicious npm packages. By 19:26 UTC, 84 malicious artifacts across 42 packages in the @tanstack namespace had landed in the npm registry. Three of them ended up in CISA's Known Exploited Vulnerabilities catalog sixteen days later.

The attack is called Mini Shai-Hulud, attributed to a threat actor cluster called TeamPCP by Snyk and Unit42 researchers. It is worth understanding how it worked, because the technique does not require compromising a developer's credentials directly.

How the attack chain worked

The attack chained three weaknesses in GitHub Actions pipeline configuration.

The first link was the pull_request_target trigger. Unlike pull_request, this trigger runs workflows with write permissions on the base repository even when triggered by a fork. TanStack's CI workflows used this trigger, which meant an external contributor with a specially crafted pull request could influence workflow execution with elevated access.

The second link was GitHub Actions cache poisoning. The TanStack build pipeline cached artifacts between workflow runs. By influencing what got written to that cache, TeamPCP was able to inject content that a subsequent legitimate workflow run would read back and execute.

The third link was OIDC token extraction. GitHub Actions provides workflows with short-lived OIDC tokens for trusted authentication to external services, including npm, via the OpenID Connect protocol. By executing code in the context of the legitimate workflow, TeamPCP extracted one of these tokens at runtime, from memory, during an actual repository build.

With a valid OIDC token in hand, the attacker could authenticate to npm as TanStack and publish packages. In six minutes, 84 malicious artifacts were live.

What the malicious packages did

The payload had two components.

The credential-stealing component harvested saved credentials from developer machines: browser-stored passwords, API keys, cloud provider credentials, and similar secrets. It sent the collected data to an attacker-controlled server.

The worm component used the same OIDC token mechanism to self-propagate: after running on a developer machine, the malware attempted to extend the compromise into that developer's own GitHub Actions pipelines by poisoning their caches in turn. This is what qualifies Mini Shai-Hulud as a worm rather than a simple infostealer.

The destructive daemon component could wipe developer home directories. Researchers believe this was intended either as a ransom mechanism or as a deterrent against forensic analysis.

Why this ended up in CISA's KEV catalog

On May 27, CISA added three CVEs to its Known Exploited Vulnerabilities catalog that trace back to this or closely related supply chain activity during the same period:

CVE-2026-45321 covers the TanStack npm supply chain compromise specifically. CVE-2026-48027 covers Nx Console, a VSCode extension that was separately compromised in a related campaign (Nx Console 18.95.0, published May 20). CVE-2026-8398 covers a Daemon Tools Lite compromise from the same broader supply chain wave.

The CISA KEV catalog generally reflects confirmed exploitation in the wild. Seeing three supply chain CVEs added in a single batch is unusual and reflects how much damage this class of attack can cause in a short window.

What developers should check now

First, audit your package-lock.json or yarn.lock files for @tanstack packages installed between May 11 and May 15, 2026. If your build system pulled @tanstack dependencies during that window without pinning exact versions, you may have executed malicious code.

Second, rotate any secrets that were accessible on developer machines used during that window. Pay particular attention to cloud provider credentials, API keys for CI/CD services, and SSH keys.

Third, review your own GitHub Actions workflows for pull_request_target usage combined with cache actions. This is the configuration combination that created the attack surface.

Fourth, consider requiring OIDC token scoping for npm publishing in your own pipelines. GitHub now supports restricting which packages a given OIDC token can publish to. Token extraction is harder to prevent than token scope abuse.

The broader issue

The npm ecosystem's supply chain security depends heavily on the integrity of the accounts and CI/CD pipelines that publish packages. Mini Shai-Hulud demonstrates that attackers do not need to steal a developer's password. They need a misconfigured pipeline and six minutes.

This is what makes GitHub Actions security foundational rather than optional. If your CI/CD pipeline has write access to npm or any other package registry, the security of that pipeline is the security of every project that installs your packages.

Gigia Tsiklauri is a Security Architect and founder of Infosec.ge. Get in touch if you are investigating a supply chain compromise or CI/CD pipeline security issue.

Related articles