TanStack OpenAI Supply Chain Attack: Mini Shai-Hulud, IOCs, and First-Hour Response Runbook

CVE-2026-45321, disclosed on May 11, 2026 and listed in the CISA Known Exploited Vulnerabilities catalog, is a critical severity (CVSS 9.6) software supply chain vulnerability in 42 @tanstack/* npm packages that let attackers publish credential-stealing malware under TanStack's trusted publishing identity, and the resulting TanStack OpenAI supply chain attack reached two OpenAI employee devices and forced OpenAI to rotate macOS, Windows, iOS, and Android code-signing certificates with a June 12, 2026 cutoff for ChatGPT Desktop, Codex App, Codex CLI, and Atlas users. This post is written for AppSec engineers, platform security teams, and DevSecOps responders working active exposure as of June 2026, and covers the full attack chain, the affected packages, the indicators of compromise, the first-hour runbook, and the structural reason conventional tooling caught the package versions but missed the behavior.

What Happened: TanStack, OpenAI, and the Mini Shai-Hulud Resurgence

The TanStack OpenAI supply chain attack is the second 2026 wave of the Mini Shai-Hulud worm, a self-propagating npm campaign attributed to TeamPCP. Attackers compromised the TanStack Router publishing pipeline, published 84 malicious versions across 42 @tanstack/* packages with valid provenance, and the resulting downstream installs and credential theft carried the campaign into Mistral AI, UiPath, the OpenSearch JS client, Guardrails AI, and two OpenAI employee devices.

OpenAI confirmed that no user data, production systems, or intellectual property were compromised or modified, that only limited credential material was transferred from internal source code repositories the two impacted employees could reach, and that no malicious software was signed with any OpenAI certificate. OpenAI isolated the affected systems, revoked user sessions, rotated credentials, and rotated platform signing certificates as a precaution because the downstream trust chain had been exposed. Primary sources for this section are the TanStack maintainer postmortem, the OpenAI incident response page, The Hacker News, Expel, StepSecurity, and Aikido.

How the Attack Chain Executes

Mini Shai-Hulud propagates by hijacking the publishing pipeline itself rather than by phishing a maintainer. The TanStack Router CI minted a legitimate OIDC publish token in runner memory, and the attacker extracted that token after a poisoned build cache delivered attacker-controlled binaries onto the release runner, then published malicious versions through the same trusted publishing flow downstream consumers rely on for provenance validation.

Initial Execution: Cache Poisoning and pull_request_target Abuse

The attacker chained a pull_request_target Pwn Request, GitHub Actions cache poisoning across the fork-to-base trust boundary, and OIDC token extraction from the runner process. Per the TanStack postmortem, no maintainer was phished and no npm token was stolen. A fork PR running under pull_request_target executed fork-controlled code in the base repository cache scope, and actions/cache@v5 saved a poisoned pnpm store under the exact key Linux-pnpm-store-6f9233a50def742c09fde54f56553d6b449a535adf87d4083690539f49ae4da11 that the production release.yml workflow would later restore.

Payload Delivery: Trusted Publishing With Valid Provenance

The compromised versions published through legitimate trusted publishing infrastructure with valid provenance metadata and signatures. Provenance was not bypassed, it was reused: the release workflow held id-token: write, and code running during the test and cleanup phase minted an OIDC token and POSTed directly to registry.npmjs.org, outside the workflow's defined publish step, so downstream tooling that validated provenance saw a correctly attested package. Each affected package received exactly two malicious versions published roughly six minutes apart, for example @tanstack/react-router@1.169.5 and @tanstack/react-router@1.169.8.

Credential Harvesting and Persistence

On install or runtime initialization, the modular Python toolkit delivered through the guardrails-ai and mistralai packages on Linux runs credential collection that covers every environment variable on the machine, all SSH keys and SSH config files, every dotenv file walked recursively from the home directory, credentials pulled from running Docker containers, GitHub credentials, npm publish tokens, Kubernetes secrets, and cloud credentials across all 19 AWS availability zones including us-gov-east-1 and us-gov-west-1. Some variants target Claude Code environments, VS Code persistence mechanisms, and developer shell startup scripts. The @tanstack/* Router payload itself ships as a roughly 2.3 MB obfuscated router_init.js smuggled into the tarball and pulled in through a malicious optionalDependencies entry referencing github:tanstack/router#79ac49eedf774dd4b0cfa308722bc463cfe5885c.

Exfiltration and Propagation: The FIRESCALE Fallback

The broader-campaign Python toolkit beacons to a primary C2 server hard-coded at 83.142.209[.]194, and when the primary is unreachable the FIRESCALE fallback activates: the toolkit searches public GitHub commit messages worldwide for a signed alternative server URL, verifies the URL against an embedded 4096-bit RSA key, then exfiltrates through three sequential paths (primary C2, FIRESCALE dead-drop redirect, and the victim's own GitHub repository), so blocking any single tier leaves the other two intact. The @tanstack/* Router payload diverges here, and the divergence is a verified TanStack-specific detail: per the TanStack postmortem, router_init.js exfiltrated over the Session and Oxen encrypted messenger network (filev2.getsession[.]org, seed{1,2,3}.getsession[.]org) with no attacker-controlled C2, which means blocking that network by IP and domain is the only network mitigation for the npm artifact specifically. Stolen credentials then drive propagation into additional packages and ecosystems.

The Campaign Connection: Why Mini Shai-Hulud Matters Beyond TanStack

Mini Shai-Hulud is the operational evolution of the original Shai-Hulud worm, and the TanStack wave is structurally significant because the campaign weaponized trusted publishing itself. Valid provenance signatures and signed CI/CD release pipelines no longer guarantee package integrity once the delivery pipeline becomes the compromise vector. The behavioral overlap with prior TeamPCP activity is consistent across waves:

• December 2025: cryptocurrency miner deployment.
• March 2026: LiteLLM PyPI compromise, Trivy scanner hijack via GitHub Actions, Checkmarx KICS attack, and Telnyx package compromise.
• Late March 2026: VECT ransomware using credentials stolen from earlier tooling.
• May 2026: Jenkins AST Plugin backdoor, then the TanStack Router wave.

Shared infrastructure ties the waves together. The 83.142.209[.]0/24 subnet was provisioned during TeamPCP's pre-campaign build-up and left dormant to accumulate clean history, with SSH active on 83.142.209[.]194 and 83.142.209[.]203 first seen on November 15 and 21, 2025, roughly four months before activation. Esteban Borges of Hunt.io confirmed the same subnet appeared across every major TeamPCP wave tracked through May 2026. What is genuinely new in this variant:

• Trusted publishing abuse with preserved provenance metadata, a reuse of valid attestation rather than a bypass.
• FIRESCALE three-tier exfiltration that uses GitHub commit messages as dead-drop infrastructure.
• Specific targeting of AI tooling, including Mistral AI, Guardrails AI, Codex tooling, and Claude Code persistence variants.
• Geographic destructive behavior: machines geolocated to Israel or Iran trigger a 1-in-6 probability gate that activates audio playback at maximum volume followed by deletion of all accessible files, while the worm exits cleanly on systems with a Russian locale, matching the kamikaze wiper pattern TeamPCP previously deployed against Iran-based Kubernetes clusters via CanisterWorm.

Indicators of Compromise (IOCs) and Behavioral Signals

Hunt for these indicators in three places: your npm and package-lock manifests for affected versions, your CI runner logs for outbound traffic to the 83.142.209[.]0/24 subnet and the Session messenger network, and your developer workstations for environment enumeration and dotenv access patterns. Install-time and runtime artifacts both matter, since static manifest checks alone will miss execution evidence.

Each @tanstack/* package received two malicious versions, for 84 versions across 42 packages. The complete per-package list is published in GitHub advisory GHSA-g7cv-rxg3-hmpx and tracking issue TanStack/router#7383. The four pairs below are the highest-traffic packages most likely to sit in your lockfiles.

Package and artifact fingerprints:

Network indicators:

Behavioral and CI/CD indicators:

Immediate Response: The First-Hour Runbook

If your environment installs from the @tanstack, @mistralai, UiPath, OpenSearch JS, or Guardrails AI namespaces, treat exposure as the default assumption until proven otherwise. Priority order: quarantine the artifacts, rotate every credential the affected runner or workstation could have seen, audit GitHub Actions and publish activity, then inspect endpoints for persistence.

1. Quarantine the affected packages by pinning lockfiles to known-good versions predating the compromise window and blocking the @tanstack/*, @mistralai/*, UiPath, OpenSearch JS, and Guardrails AI ranges at your registry proxy.
2. Determine whether the affected packages executed and not only installed, using CI build logs, install scripts, and runtime initialization traces as the source of truth.
3. Rotate every credential the affected runner or workstation could have touched: npm publish tokens, GitHub personal access tokens and OIDC config, SSH keys, AWS credentials across all 19 availability zones including GovCloud, Kubernetes secrets, and any credentials stored in environment variables or dotenv files.
4. Audit GitHub Actions runs across affected repositories for pull_request_target triggers, unexpected publish events, OIDC issuance with no matching tagged release, and cache hits inconsistent with prior runs.
5. Inspect developer workstations for persistence: daemonized processes, Linux service creation, shell startup script edits, VS Code persistence artifacts, and Claude Code environment changes.
6. Hunt for outbound traffic to 83.142.209[.]0/24 and the Session messenger network, plus anomalous GitHub commit-search API calls from CI or developer hosts (FIRESCALE dead-drop lookup).
7. Freeze code-signing and release workflows until rotation completes, following the OpenAI precedent of rotating signing certificates even under limited exposure.
8. Document and notify internal stakeholders, dependent teams, and any downstream customers consuming your published artifacts.

Why Conventional Tooling Caught the Packages but Missed the Behavior

Static SCA scanners and provenance validation both performed exactly as designed during the TanStack OpenAI supply chain attack, and both missed the compromise: provenance was reused rather than bypassed, and manifest scanning sees package versions, not what those packages do at install or runtime. The structural gap sits between knowing what is installed and knowing what that code does once it executes.

Static SCA yields an inventory that proves a package and version are present but says nothing about whether the install hook ran, whether dotenv files were read, or whether persistence was established. Signature-based detection would not have flagged trusted-publishing artifacts at publish time, and provenance validation confirms only that a package came from a registered workflow, not that the workflow stayed uncompromised.

Runtime intelligence closes that gap by observing what packages do once they execute. Kodem's Runtime SCA correlates dependency inventory with runtime execution traces, so a malicious install hook reading SSH keys or a build script calling an unfamiliar C2 subnet surfaces as behavior rather than metadata. Kodem's Application Detection and Response (ADR) catches the runtime stage of campaigns like Mini Shai-Hulud: credential file reads from build tooling, anomalous outbound traffic from CI runners, unexpected child processes from npm install, and the persistence artifacts attackers leave on developer workstations. For the prior wave, see the Kodem Mini Shai-Hulud PyTorch Lightning and Intercom breakdown from April 30, 2026.

Hardening Your Pipeline Against the Next Variant

Assume more Mini Shai-Hulud variants are coming. TeamPCP announced a $1,000 Monero contest for compromising additional open-source packages using a freely distributed Shai-Hulud worm, which means the attack pattern is now operationally available to any motivated actor. Harden the publishing pipeline, scope tokens narrowly, and add runtime monitoring to the layers static tooling cannot see.

1. Restrict GitHub Actions permissions to least privilege per workflow, and disable pull_request_target triggers unless explicitly required.
2. Reduce token scope and lifetime so that OIDC tokens scoped to a single registry and repository limit blast radius when, not if, a runner is compromised.
3. Pin GitHub Actions to commit SHAs rather than tags, so a compromised maintainer cannot push an updated action under the same reference.
4. Isolate the publish step on a separate runner with no source access beyond what publishing requires, and scope the publish token to that runner only.
5. Add runtime monitoring for developer tooling and CI, since static inventory and provenance validation cannot see install-time behavior, environment variable reads, or outbound exfiltration.
6. Treat AI development environments as Tier 0 infrastructure, because they centralize the cloud credentials, deployment pipelines, repository access, and privileged tooling TeamPCP targeted across Mistral AI, OpenAI repositories, Guardrails AI, and Claude Code in this wave.
7. Pre-authorize a code-signing rotation playbook, since rotating macOS, Windows, iOS, and Android certificates as a precaution is now the operational baseline.

What This Incident Reveals About Where Supply Chain Attacks Are Going

The TanStack OpenAI supply chain attack is the clearest evidence yet that attackers target the delivery pipeline, not the application. Trusted publishing, signed provenance, and official release infrastructure stop guaranteeing integrity once CI/CD execution paths are compromised.

• AI development ecosystems are now Tier 1 targets, aggregating credentials, deployment pipelines, repository access, and automation in one place.
• The provenance trust question is shifting from whether a package was signed by the right workflow to whether that workflow was still trustworthy at publish time.
• Worm tooling is commoditized: TeamPCP distributes Shai-Hulud freely and runs a $1,000 Monero contest for new compromises.

One falsifiable prediction: the next Mini Shai-Hulud wave lands within 60 to 90 days, hitting either a major AI SDK outside the @tanstack and @mistralai namespaces or a widely used GitHub Actions reusable workflow. Watch for renewed C2 activity outside the now-attributed 83.142.209[.]0/24 subnet.

Frequently Asked Questions

1. What is Mini Shai-Hulud? Mini Shai-Hulud is the 2026 evolution of the Shai-Hulud npm worm, a self-propagating supply chain campaign attributed to TeamPCP that uses compromised CI/CD publishing workflows to push malicious package versions through trusted publishing infrastructure with valid provenance signatures. The TanStack wave (May 10 to May 19, 2026) is the second major Mini Shai-Hulud campaign of the year.

2. Which TanStack packages are compromised? The initial wave included 84 malicious versions across 42 @tanstack/* packages, with two malicious versions per package, for example @tanstack/react-router@1.169.5 and @tanstack/react-router@1.169.8. The campaign expanded to 169+ affected package names and 373+ malicious versions across @tanstack/*, @mistralai/*, UiPath packages, the OpenSearch JS client, and Guardrails AI. Refer to GitHub advisory GHSA-g7cv-rxg3-hmpx and the TanStack maintainer postmortem for the exact version strings.

3. Was OpenAI breached? OpenAI confirmed two employee devices were impacted and that limited credential material was transferred from internal source code repositories those employees could reach. OpenAI stated that no user data, production systems, or intellectual property were compromised or modified, and found no evidence of malicious software signed with any OpenAI certificate. The company isolated the impacted systems, revoked user sessions, rotated credentials, and rotated macOS, Windows, iOS, and Android code-signing certificates as a precaution, with a June 12, 2026 deadline for macOS app updates.

4. What credentials does the malware steal? The modular Python toolkit harvests environment variables, SSH keys and SSH config, dotenv files walked recursively from the home directory, credentials from running Docker containers, GitHub tokens, npm publish tokens, Kubernetes secrets, and AWS credentials covering all 19 availability zones including the GovCloud regions us-gov-east-1 and us-gov-west-1.

5. How does this differ from the original Shai-Hulud? The original Shai-Hulud worm propagated through compromised maintainer accounts and stolen tokens. The TanStack wave of Mini Shai-Hulud propagated through the publishing pipeline itself, reusing valid provenance signatures rather than bypassing them, and added the FIRESCALE fallback (using GitHub commit messages worldwide as a dead-drop for alternative C2 URLs verified by an embedded 4096-bit RSA key) plus three-tier exfiltration redundancy.

6. Can my existing SCA tool detect this attack? Static SCA can identify the affected package versions in your manifest once IOCs are published, which is necessary but not sufficient. Static SCA cannot tell you whether the install hook executed, whether credentials were exfiltrated, or whether persistence was established on a developer workstation. Detecting the runtime stage requires behavioral monitoring of install and runtime activity.

7. What is the fastest way to stop propagation? Quarantine the affected packages at your registry proxy, rotate every credential the affected runner or workstation could have seen (especially GitHub tokens, npm publish tokens, SSH keys, and cloud credentials), and freeze code-signing and release workflows until rotation completes. Credential rotation is the propagation circuit-breaker, because the worm reuses stolen credentials to publish into additional packages.

8. Where can I track future Mini Shai-Hulud variants? Primary sources for ongoing variant tracking are the TanStack maintainer blog, the OpenAI incident response page for AI ecosystem impact, Hunt.io for TeamPCP infrastructure tracking, StepSecurity and Aikido for self-propagating supply chain research, and Expel for cross-ecosystem analysis. Watch for new C2 activity outside the 83.142.209[.]0/24 subnet, since publicly attributed infrastructure is unlikely to be reused.

The TanStack OpenAI supply chain attack succeeded because static SCA and provenance validation could only see the package, not what the package did. Kodem's Runtime SCA and Application Detection and Response surface the install-time and runtime behavior that signature-based tooling structurally cannot catch, from credential reads inside build hooks to outbound calls to attacker-controlled subnets like 83.142.209[.]0/24.

References

1. Expel. May 2026. Mini Shai-Hulud: cross-ecosystem supply chain worm targeting npm and PyPI. Expel.
2. GitHub. May 2026. Malware in @tanstack/* packages exfiltrates cloud credentials, GitHub tokens, and SSH keys (GHSA-g7cv-rxg3-hmpx, CVE-2026-45321). GitHub.
3. iTnews. May 2026. Mini Shai-Hulud worm injects disk wiper into Microsoft Azure PyPI package. iTnews.
4. Kodem Security. April 30, 2026. Mini Shai-Hulud Strikes PyTorch Lightning and Intercom Client: Inside the Cross-Ecosystem Supply Chain Attack. Kodem Security.
5. KrebsOnSecurity. March 2026. CanisterWorm Springs Wiper Attack Targeting Iran. KrebsOnSecurity.
6. NVD. May 12, 2026. CVE-2026-45321 Detail. NVD.
7. OpenAI. May 2026. Our response to the TanStack npm supply chain attack. OpenAI.
8. StepSecurity. May 2026. TeamPCP's Mini Shai-Hulud Is Back: A Self-Spreading Supply Chain Attack Hits the npm Ecosystem. StepSecurity.
9. TanStack. May 11, 2026. Postmortem: TanStack npm supply-chain compromise. TanStack.
10. Tenable. May 21, 2026. Mini Shai-Hulud Supply Chain Attack CVE-2026-45321 FAQ. Tenable.
11. The Hacker News. May 2026. TanStack Supply Chain Attack Hits Two OpenAI Employee Devices, Forces macOS Updates. The Hacker News.
12. The Hacker News. May 2026. Mini Shai-Hulud Worm Compromises TanStack, Mistral AI, Guardrails AI & More Packages. The Hacker News.