John Z Black
Brunswick, ME • (207) 245-1010 • contact@johnzblack.com
On March 31, a malicious version of the Axios npm package executed inside one of OpenAI’s GitHub Actions signing workflows. The workflow had access to macOS signing certificates for ChatGPT Desktop, Codex, Codex CLI, and Atlas.
OpenAI’s investigation found no evidence the signing keys were actually stolen. Timing, sequencing, how the certificate was injected into the job — all of it suggested the keys were probably fine.
They revoked and rotated them anyway.
That’s the right call. It’s also rare enough to be worth noting.
Once a malicious package executes inside a signing environment, the trust properties of everything that environment touched become suspect in a way forensic investigation can’t fully clear. OpenAI’s advisory is explicit: “Nevertheless, out of an abundance of caution we are treating the certificate as compromised.” That word “nevertheless” is doing serious work. They’re not saying they found a breach. They’re saying the cost of being wrong is too high to accept even a low probability.
Effective May 8, older versions of those four apps will stop receiving updates and may stop working entirely. For individual users: update before May 8. For enterprise IT managing standardized deployments: you’ve got a real project on your hands. Four products, potentially a lot of managed endpoints, hard deadline.
The root cause is familiar. OpenAI’s workflow used a floating tag instead of pinning to a specific commit hash. Tags are mutable. Someone updated it to point to malicious code. A pinned commit hash can’t be changed after review.
The practical lesson for any CI/CD pipeline with a signing step: pin to commit hashes, not tags. Separate signing from building. Have a revocation runbook before you need it, not after. OpenAI could rotate fast. Not everyone can.
Supply-chain blast radius looks like this: one bad dependency, four products affected, a hard deadline hitting users in three weeks.