TanStack supply-chain breach forces OpenAI code-signing rotation

TL;DR - The TanStack npm compromise (Mini Shai-Hulud campaign) reached two OpenAI employee devices on 11 May 2026, exfiltrated limited credentials from internal repos, and exposed code-signing certificates for macOS, iOS, and Windows products. OpenAI is rotating those certificates. If you run OpenAI macOS apps, update before 2026-06-12 or your installs will stop trusting the new signing chain.

What happened

OpenAI ships developer-facing desktop and CLI software - ChatGPT Desktop, Codex CLI, Atlas, and others - that depends on OS-level code-signing and notarisation for trust. On 11 May 2026 (UTC), OpenAI disclosed that the TanStack npm compromise, part of the broader Mini Shai-Hulud supply-chain campaign, reached two devices inside its corporate environment.

Behaviour matched public descriptions of the malware: unauthorised access and credential-focused exfiltration from a limited subset of internal source code repositories accessible to those employees. Only limited credential material left the building. OpenAI says it has found no evidence of impact to customer data, production systems, intellectual property, or deployed software.

The operationally sharp part: the affected repos held code-signing certificates for OpenAI products, covering macOS, iOS, and Windows. OpenAI is rotating those certificates now. Because macOS ties trust to notarisation chains, existing installations signed with the old certificates will stop working after revocation. That is why there is a hard deadline.

This is a clean illustration of why supply-chain incidents do not stop at dependency graphs. Once an attacker reaches build inputs and signing material, they can attack trust distribution itself - the same blast-radius pattern documented in /research/supply-chain and covered in depth in /guides/cicd-security.

Who is impacted

• macOS users of OpenAI desktop apps: certificate rotation requires you to move to newly signed builds before the cutoff.
• Organisations distributing internal macOS apps or developer tooling with privileged local access: this is the exact failure mode you get when signing keys and notarisation workflows are exposed via a compromised developer endpoint.
• Security and platform teams consuming npm packages in corporate dev environments: this incident is downstream of a campaign that specifically targets developer credentials and CI/CD pathways. If your engineers ran affected TanStack packages during the campaign window, scope that separately.

What to do now

• Update your OpenAI macOS apps before 2026-06-12. After that date, certificate revocation will make older signed builds untrusted.

  "Update your macOS applications by June 12, 2026"

• Use OpenAI's in-app update mechanism. Avoid third-party installers.

  "You can update safely through an in-app update"

• If you manage device fleets via MDM, plan enforcement now. Don't let the deadline catch developer tooling mid-session.
• If your engineers installed compromised TanStack-related packages during the campaign window, treat it as a potential credential exposure:
  • review CI/CD identity and token grants
  • rotate any secrets accessible from affected dev endpoints
  • audit repo access logs for that window
• Use this as a prompt to harden your own signing and build pipeline:
  • inventory where signing keys, notarisation credentials, and release identities live
  • restrict access paths from developer endpoints to signing material
  • tighten dependency intake controls: lockfiles, provenance verification, scoped registries - all covered in /guides/secure-dependency-management

Why this matters for AppSec

Code-signing certificates are a trust primitive, not just a compliance checkbox. When an attacker reaches them - even indirectly, through a compromised developer workstation rather than your signing infrastructure directly - the downstream effect is that every build you ship becomes suspect until you rotate and revoke.

The Mini Shai-Hulud campaign targeted developer tooling because that is where credentials concentrate: npm tokens, cloud access keys, repo secrets, and, in this case, signing material. The vector was a dependency, not a firewall bypass. That is the threat model most platform teams still under-invest in.

Three concrete takeaways:

1. Signing material needs the same access controls as production secrets. If a developer laptop can reach your notarisation credentials, so can anything running on that laptop.
2. Certificate rotation has a user-facing deadline. Build the rotation procedure before you need it, not during the incident.
3. Scope your npm dependency exposure proactively. If you cannot answer "which packages from this campaign window did our CI runners install?", that is a gap worth closing before the next campaign.