OpenAI — two employee devices compromised in TanStack npm supply-chain attack

What happened

Between 10 and 12 May 2026 the crew tracked as TeamPCP ran a self-propagating supply-chain worm across the npm ecosystem — and, at the margins, PyPI — that researchers named Mini Shai-Hulud, after the larger Shai-Hulud npm worm of the previous year. On 11 May the campaign published 84 malicious versions across 42 official @tanstack/* packages, including widely used components such as @tanstack/react-router and @tanstack/router-core. Within hours it had spread on its own to more than 169 packages and over 373 malicious versions, sweeping up projects belonging to OpenSearch, Mistral AI, Guardrails AI, UiPath and several SAP developer tools along the way. TanStack packages alone are downloaded tens of millions of times a week, so the exposure window was enormous.

OpenAI confirmed on 29 May that two employee devices in its corporate environment had installed the poisoned releases and were compromised before detection. The company’s incident statement is unusually specific. The malware behaved as publicly described — credential-focused theft from local secrets stores and directory walks across the obvious developer locations — and OpenAI says a limited amount of credential material was successfully exfiltrated from a small subset of the internal source-code repositories those two staff members could access. On the current evidence no customer data, production systems, intellectual property or shipped code were affected.

The cost of this incident is in the cleanup rather than the loss. Among the credentials the attackers reached were OpenAI’s application-signing keys for Windows, macOS, iOS and Android. As a result the company is re-signing every desktop and mobile application it ships and revoking the old certificates. macOS users were given a hard deadline of 12 June 2026, after which applications signed with the previous certificate would be blocked at launch by Gatekeeper. Two poisoned laptops, in other words, forced a company-wide re-issuing of software.

How it worked

The entry point was not a stolen password but a forgotten piece of trust. An orphaned commit in a TanStack CI workflow still had OpenID Connect (OIDC) trust federation configured with npm — a standing arrangement that let TanStack’s automation publish packages without a long-lived token. The attacker extracted an OIDC token from the CI runner process and exchanged it for authenticated publish access across the entire TanStack namespace. From a single misconfigured pipeline, they could sign and ship code as a trusted maintainer.

What made this a worm rather than a one-off poisoning was the self-propagation logic. Each compromised package version carried an npm preinstall hook that fired automatically the moment a developer or CI system installed it. The hook downloaded the Bun JavaScript runtime as a living-off-the-land binary — a legitimate tool used to run the payload without tripping controls tuned for Node — and launched a 2.3 MB obfuscated payload, router_init.js. That payload swept the environment for CI secrets, cloud-provider credentials, Kubernetes tokens and HashiCorp Vault secrets, using the open-source scanner TruffleHog to hunt for anything credential-shaped. Crucially, when it found npm and GitHub publishing credentials, it did not just exfiltrate them. It enumerated every package that the newly compromised maintainer controlled and published infected versions of each. Every infected CI run became a new publisher, and the campaign expanded outward from TanStack into more than a hundred additional packages without any further action from the operators.

For OpenAI, the chain from exposure to impact was short. Two engineers installed tainted @tanstack releases during routine work. The payload harvested credential material from their workstations, including access to a small number of internal repositories and — the consequential part — the organisation’s application-signing keys. There was no need for the attacker to breach OpenAI’s production estate or move laterally through its network. The developer workstation and the credentials cached on it were close enough to the software-signing pipeline that a single poisoned dependency put the trust anchor for every shipped OpenAI app within reach.

Timeline

• 10–12 May 2026 — TeamPCP runs the Mini Shai-Hulud self-propagating worm across npm and some PyPI packages.
• 11 May 2026 — 84 malicious versions published across 42 official @tanstack/* packages; the worm self-propagates to 169+ packages and 373+ versions within hours, hitting OpenSearch, Mistral AI, Guardrails AI, UiPath and SAP developer tools.
• ~15 May 2026 — early reporting places OpenAI among the affected organisations after two employee devices install the poisoned releases.
• 29 May 2026 — OpenAI confirms the breach, states a limited amount of credential material was exfiltrated, and begins re-signing all desktop and mobile applications while revoking old certificates.
• 12 June 2026 — hard deadline for macOS users to update; applications signed with the previous certificate are blocked by Gatekeeper after this date.

What defenders should learn

The headline lesson is not about OpenAI; it is about what two compromised laptops were sufficient to reach. A poisoned third-party npm package, installed once during an ordinary workday, put an attacker close enough to the application-signing pipeline that every shipped artefact had to be re-issued. The developer workstation is now a high-value target precisely because it sits adjacent to secrets, source and signing material, and the blast radius of a single dependency is measured by whatever those workstations can touch.

That reframes the defensive priority around the software pipeline itself, and this is where the segmentation and Zero Trust lens goes — worth Andy expanding. Two structural controls would each have blunted this attack. The first is standing trust: the whole campaign pivoted on an orphaned OIDC federation and long-lived publishing rights, so ephemeral, tightly scoped publish credentials and a routine audit for forgotten trust relationships remove the initial pivot. The second is the workstation blast radius: application-signing keys should not be retrievable from an engineer’s laptop at all. Signing belongs behind a hardware-backed, access-brokered service that a developer can invoke but never export, so that a compromised endpoint yields, at worst, a request to sign — not the key itself. The same segmentation principle that keeps a breached user off the crown jewels applies to the pipeline: assume the workstation will be compromised and make sure that compromise cannot reach the trust anchor.

There are also immediate, executable controls that OpenAI itself adopted and that any engineering organisation can copy this week: enforce an npm install delay (minimumReleaseAge) so brand-new package versions cannot be pulled into a build the moment they publish, turn on package provenance and signature verification, add package-validation tooling to engineer workstations, and treat preinstall and postinstall lifecycle scripts as hostile by default. Mini Shai-Hulud is the third TeamPCP campaign in this catalogue, after the Bitwarden CLI and GitHub internal-repository compromises, and the pattern across all three is the same: the open-source dependency graph is now a self-propagating delivery mechanism, and the credential a developer leaves cached on their machine is the payload it is hunting for.