When OpenAI disclosed on April 11 that a compromised Axios npm package had executed inside its macOS app-signing workflow, it confirmed what many of us in infrastructure already suspected. Supply chain attacks are no longer theoretical risks for CI/CD — they are actively reaching code signing credentials in production pipelines.

This is not a story about a JavaScript library. It is a story about how a single misconfigured GitHub Actions workflow nearly gave a North Korean state actor access to the certificates that macOS uses to trust ChatGPT, Codex, and Atlas on every Apple device.

What Happened at OpenAI

On March 31, 2026, two malicious versions of Axios — 1.14.1 and 0.30.4 — were published to npm. Microsoft Threat Intelligence attributed the attack to Sapphire Sleet, a North Korean state actor that has been active since at least 2020, primarily targeting cryptocurrency and blockchain organisations.

The malicious versions did not modify the Axios source code. Instead, they injected a dependency called plain-crypto-js@4.2.1, which executed a postinstall script during npm install. That script connected to attacker-controlled infrastructure at sfrclak[.]com on port 8000 and downloaded a platform-specific remote access trojan — native binary on macOS, PowerShell on Windows, Python on Linux.

OpenAI’s macOS app-signing GitHub Actions workflow pulled the compromised Axios version at runtime. The workflow had access to the certificates used to notarize OpenAI’s macOS desktop applications. That means the signing material that tells every Mac “this software is legitimate” was potentially reachable by the attacker’s payload.

OpenAI reported that multiple mitigating factors likely prevented actual exfiltration. But they treated the certificates as compromised anyway, which was the right call.

The Root Cause Was a Misconfigured GitHub Actions Workflow

OpenAI’s post-incident disclosure was unusually specific about what went wrong:

The root cause of this incident was a misconfiguration in the GitHub Actions workflow. Specifically, the action in question used a floating tag, as opposed to a specific commit hash, and did not have a configured minimumReleaseAge for new packages.

Two configuration gaps. That is all it took.

Using a floating tag means the workflow resolves whatever the latest version is at runtime. No human review. No gate. If a compromised version is published to npm, it gets pulled into the next build automatically.

Not setting minimumReleaseAge — a relatively new npm feature — means there is no cooling-off period between when a package is published and when it can be installed. The malicious Axios versions were available immediately, and any pipeline that ran npm install in that window got the payload.

In my experience, these two patterns are everywhere. Most teams I work with use caret or tilde versioning in package.json and have never heard of minimumReleaseAge. Their GitHub Actions workflows reference actions by tag, not by commit SHA. The OpenAI incident is notable because they disclosed it — not because the misconfiguration is unusual.

What OpenAI Did in Response

The response was textbook for a signing credential exposure:

• Revoked and rotated the macOS code signing certificate
• Rebuilt all affected applications with new credentials
• Required macOS users to update to the latest versions of ChatGPT Desktop, Codex, and Atlas
• Coordinated with Apple to block further notarization attempts using the previous certificate
• Set a deadline: older versions will stop receiving updates and may stop functioning after May 8, 2026

No evidence of user data compromise or production system breach was reported. But the operational cost of rotating signing certificates, rebuilding applications, and forcing an update cycle across your entire macOS user base is significant. That is real engineering time and real user friction, triggered by a dependency misconfiguration.

Why This Matters Beyond OpenAI

The pattern that exposed OpenAI exists in thousands of organisations right now.

GitHub Actions workflows are the most common CI/CD platform for open-source and increasingly for enterprise. Most of those workflows install dependencies at runtime. Most use version ranges, not pinned versions. Most do not restrict postinstall scripts. And most have access to secrets — deployment keys, cloud credentials, signing certificates, API tokens — because that is how CI/CD works.

The attack chain is straightforward: compromise a popular npm package, inject a postinstall hook, wait for CI systems to pull the new version automatically, and harvest whatever secrets the runner can access. The Axios attack targeted the most downloaded HTTP client in the JavaScript ecosystem — over 70 million weekly installs. The blast radius was enormous by design.

What makes the OpenAI case distinct is the target. Code signing certificates are the root of trust for software distribution on macOS. If an attacker obtains a valid signing certificate, they can distribute malware that appears to come from a trusted vendor. That is one of the most dangerous outcomes in the entire supply chain attack taxonomy.

Five Things to Audit in Your GitHub Actions Right Now

I have been reviewing CI/CD configurations with clients for years, and the same gaps appear repeatedly. Here is what to check:

Pin dependencies to exact versions. Remove ^ and ~ from package.json for any package that sits in your build pipeline. Yes, this means you manually manage version bumps. That is the point. Automatic version resolution is exactly the mechanism this attack exploited.

Pin GitHub Actions to commit SHAs, not tags. Tags can be moved. A compromised action can republish a tag pointing to malicious code. Commit SHAs are immutable. Replace uses: actions/checkout@v4 with uses: actions/checkout@. This is GitHub’s own recommendation after the recent tj-actions/changed-files compromise.

Set minimumReleaseAge for critical packages. npm now supports a cooldown period before newly published versions can be installed. This would have blocked the Axios attack entirely, since the malicious versions were published and consumed within the same window. Configure it in your .npmrc.

Disable or restrict postinstall scripts. Run npm ci --ignore-scripts in your build pipeline unless you explicitly need lifecycle hooks. If specific packages require them, isolate those builds and audit the scripts. The Axios attack relied entirely on a postinstall hook to execute its payload.

Audit secrets exposure in your workflows. Every GitHub Actions secret available to a workflow is available to every step in that job. If your build job has access to signing credentials, deployment keys, or cloud tokens, a compromised dependency in that same job can reach them. Separate build steps from signing steps. Use job-level isolation. Apply the principle of least privilege to your CI runners.

The Bigger Pattern

This is the third major supply chain attack in 2026 that has directly targeted CI/CD pipelines. The Trivy GitHub Actions tag compromise in March exposed CI/CD secrets across affected pipelines. The tj-actions incident demonstrated that GitHub Action tags can be hijacked. Now the Axios attack shows that even standard npm install in a build workflow can introduce a state-sponsored RAT into your signing infrastructure.

The pattern is clear: attackers are not just targeting application code. They are targeting the systems that build, sign, and deploy application code. CI/CD pipelines have become the highest-value targets in the software supply chain because they sit at the intersection of trust, automation, and credential access.

If your GitHub Actions workflows have not been audited for dependency pinning, action pinning, secret scoping, and script execution controls in the last 90 days, treat this as your signal to start. The OpenAI disclosure gave us a detailed case study of what happens when these controls are missing — even at an organisation with world-class engineering resources.

The configuration changes are not complex. The hard part is accepting that your build pipeline is an attack surface, not just a convenience layer.

• I Let GitHub Copilot Write an Entire Feature From a Spec. Here’s What Happened.
• How to Evaluate Agent Platforms in 2026 with Identity First in Mind
• I Asked Copilot to Build an Agent That Builds Other Agents. It Worked.
• OpenAI Agents SDK vs LangGraph in 2026 What CIOs should standardise on
• The Hidden Risk in Enterprise Agentic AI and Silent Failures