OpenAI has disclosed that two employee devices were impacted by the TanStack npm supply-chain attack, a credential-stealing campaign tied to the broader Mini Shai-Hulud wave. OpenAI says it found no evidence that user data, production systems, intellectual property, software builds, customer passwords, or API keys were compromised.
That is the reassuring part. The uncomfortable part is the path in: a trusted open-source dependency and a legitimate build pipeline. For software teams, this is another reminder that package signing and provenance reduce risk, but they do not remove the need to harden CI workflows, caches, and developer machines.
The security deadline for Mac users
OpenAI said the incident exposed limited credential material from internal source code repositories available to the affected employees. Some of those repositories included signing certificates for OpenAI products across iOS, macOS and Windows.
As a precaution, OpenAI is rotating code-signing certificates. The practical user impact is narrow but important: macOS users need to update OpenAI apps by June 12, 2026. Once the previous certificate is fully revoked, older macOS builds signed with it may stop launching under macOS security protections.
OpenAI says Windows and iOS users do not need to take action, and it warned users to update only through official OpenAI channels rather than links in emails, messages, ads, or third-party download sites.
How the TanStack attack spread
TanStack’s own postmortem says attackers published 84 malicious versions across 42 @tanstack packages on May 11. The affected versions were detected quickly, deprecated within the hour, and later removed by npm. TanStack says all currently available TanStack packages are safe to install.
The attack chain matters more than the raw package count. TanStack says the attackers abused a risky pull_request_target workflow pattern, poisoned a GitHub Actions cache, and extracted a GitHub Actions OIDC token from runner memory. That token was then used to publish malicious packages through npm trusted publishing.
In plain English: the attackers did not need to steal an npm password. They found a way to make the legitimate release machinery do the publishing for them.
Security researchers at Wiz and Snyk described the campaign as a credential-stealing, self-propagating worm affecting npm and PyPI ecosystems beyond TanStack, including packages associated with Mistral AI and UiPath. Snyk also noted that some malicious packages carried valid SLSA Build Level 3 provenance because the compromised pipeline itself produced them.
Why provenance was not a silver bullet
Provenance is still useful. It helps teams answer where a package came from, which workflow produced it, and whether it matches an expected build path. But this incident shows the hard limit: provenance can tell you a package came from the official pipeline even when the pipeline has been tricked.
That shifts the security question upstream. Teams need to review which workflows run on untrusted pull requests, whether caches can cross trust boundaries, how OIDC tokens are scoped, and whether release jobs can be influenced by artifacts from earlier CI steps.
The old mental model was simpler: protect the package registry token. The newer model is broader: protect the identity, runner, cache, workflow permissions, dependency install step, and release environment together.
What developers should do now
Teams that installed affected TanStack versions on May 11 should follow TanStack’s guidance and treat those hosts as potentially compromised. That means rotating reachable credentials for cloud accounts, GitHub, npm, SSH, Kubernetes, Vault, and CI systems.
For everyone else, the lesson is operational. Pin and monitor dependencies, separate untrusted PR workflows from privileged release workflows, avoid restoring caches across trust boundaries, keep OIDC permissions narrow, and make release jobs boring enough that a poisoned test run cannot become a package publish.
The TanStack and OpenAI disclosures are useful because they are specific. They show a modern supply-chain failure in detail: not a stolen password, not a mysterious zero-day, but a chain of small trust assumptions that lined up. That is exactly the kind of failure security teams need to design against next.
