Recap: what happened (and why it keeps happening)

By now you’ve seen the headline version: attackers compromised a maintainer account and published malicious Axios versions (1.14.1 and 0.30.4) that pulled in a dependency (plain-crypto-js) with a postinstall hook. Install the package, and you get stage-2 payloads for macOS, Windows, and Linux. Congratulations, your build step is now a delivery mechanism.

Elastic’s write-up adds a detail that should haunt every org that ships software: the attacker flipped both the latest and legacy dist-tags to compromised releases, so default installs and “we’re stuck on the old API” installs were both served the poisoned cup.

Why this is really an identity and provenance story

The modern JS ecosystem has a dirty secret: “trust” is mostly an email address and a package name. If an attacker can take over the account, they can publish. If they can publish, they can execute code during install. And if they can execute code during install, they can hunt for the one place you keep the keys to the kingdom (CI/CD secrets, signing material, cloud tokens, the whole cursed piñata).

Elastic highlights an especially clean signal: the publishing pattern changed. Legit releases used a GitHub Actions OIDC trusted publisher flow with SLSA provenance attestations. The malicious ones were published via direct CLI with no provenance trail, and even the maintainer email changed. That is the kind of “this is obviously wrong” detection you can automate, if you decide you actually want to.

OpenAI’s own incident report: the moment the supply chain hit the signing pipeline

OpenAI’s postmortem is blunt about the mechanism: a GitHub Actions workflow used in its macOS app-signing process downloaded and executed the malicious Axios (1.14.1). That workflow had access to code-signing certificate and notarization material for multiple macOS products (ChatGPT Desktop, Codex, Codex-cli, Atlas).

OpenAI says it found no evidence of user data access, IP compromise, or altered software, and that the signing certificate likely wasn’t successfully exfiltrated due to sequencing and other mitigations. Still, they treated it as compromised and rotated and revoked the certificate, with a May 8, 2026 deadline after which older macOS app versions may stop functioning.

The Mechanism Test: what changes if registries enforce provenance by default?

Here’s the fork in the road:

• Option A: Provenance stays optional. Enterprises keep building local patchwork (pinning, allowlists, scanners), attackers keep climbing the same ladder, and we all pretend that “don’t run npm install” is an actionable strategy.
• Option B: Provenance becomes a gate. High-impact packages must publish via verified pipelines (OIDC, commit-hash pinning, minimum release ages, signed attestations). Break the chain, and the registry treats it as suspicious by default.

Elastic basically hands you the detector: “OIDC + provenance yesterday, direct CLI today” is an anomaly worth blocking or at least screaming about. Microsoft’s mitigation guidance reinforces the boring advice (downgrade to safe versions, rotate secrets), but the deeper point is that we keep relying on after-the-fact remediation because the baseline still assumes publishers are honest and accounts are safe.

Why this matters more for AI companies (yes, again)

AI labs are becoming desktop software vendors, compiler toolchains, agent runtimes, and cloud platforms all at once. That means more CI/CD, more dependencies, more signing keys, and a bigger blast radius when something “small” is poisoned upstream. The Axios incident didn’t target “AI” in a mystical sense. It targeted where the keys live, and AI companies have a lot of keys.