OpenAI Confirms TanStack npm Worm Breach: No Customer Data Accessed

On Wednesday, OpenAI disclosed that two corporate laptops were compromised in a supply-chain attack on TanStack npm packages. The breach, attributed to the Mini Shai-Hulud worm, did not affect customer data or OpenAI products. However, limited credential material was exfiltrated from internal code repositories.

The Attack: OIDC Token Theft via GitHub Actions

The interesting part is how the malicious packages got published. On May 11, between 19:20 and 19:26 UTC, 84 malicious artifacts were published across 42 packages in the @tanstack namespace, including @tanstack/react-router, which alone pulls more than 12.7 million weekly downloads.

The attacker did not phish an npm credential. Instead, they hijacked TanStack's own release pipeline by taking over the GitHub Actions runner mid-workflow. The runner used its trusted OIDC identity to publish packages, but the attacker exfiltrated the OIDC token directly from the runner's process memory. TanStack maintainer Tanner Linsley called it the first documented npm worm with a valid signed certificate of authenticity.

Mini Shai-Hulud: A Self-Replicating Worm

Mini Shai-Hulud is a descendant of the worm that first hit npm in September 2025. It has now compromised over 170 packages across npm and PyPI, including releases from Mistral AI, UiPath, OpenSearch, and Guardrails AI. Cumulative download count of affected packages exceeds 518 million, per OX Security. Microsoft Security Research tracks it as the same campaign as Shai-Hulud 2.0 from late 2025.

The worm chains three GitHub Actions vulnerabilities: a pull_request_target trigger, cache poisoning, and OIDC token extraction from runner memory. This bypasses trusted publishing, the system designed to replace stealable npm tokens with short-lived OIDC tokens.

OpenAI's Response and Impact

OpenAI has not specified which TanStack package was pulled. Affected machines were isolated, and credential rotation is underway. Code-deployment workflows are temporarily restricted, and code-signing certificates are being rotated — hence the forced macOS ChatGPT desktop app updates this week.

OpenAI is drawing a line between its corporate engineering environment (where the breach happened) and its product surface (where nothing was touched). This distinction is critical: it's a workplace IT incident, not a customer-facing security event.

Wider Implications for npm Ecosystem

For developers publishing or consuming npm packages, the takeaway is longer. The TeamPCPa-ttributed campaign behind Mini Shai-Hulud also compromised Aqua Security's Trivy scanner in March and Bitwarden CLI npm package in April. There is no indication it has run out of targets.

Trusted publishing assumed the runner was trustworthy. The attacker made it not. The defense relied on the runner's integrity, but the worm extracted the OIDC token from memory. This undermines the security model of OIDC-based publishing.

Concrete Steps to Protect Your Pipeline

  1. Audit GitHub Actions workflows for pull_request_target triggers. This event gives the runner access to repository secrets and should be used with extreme caution.
  2. Implement runner isolation: Use self-hosted runners with minimal permissions, or use ephemeral runners for each build. Avoid reusing runners across workflows.
  3. Monitor OIDC token usage: Enable logging for OIDC token issuance and usage. Alert on unexpected token use outside normal build times.
  4. Pin dependencies and action versions: Use commit SHAs instead of tags to prevent supply-chain injection via compromised actions.
  5. Rotate credentials regularly: Even with OIDC, rotate code-signing certificates and npm tokens periodically.

The Bottom Line

Mini Shai-Hulud is a wake-up call for the npm ecosystem. The attack exploited the very mechanism designed to improve security. For OpenAI, the damage was contained. For everyone else, the question is how to trust the runner when the runner can be compromised.