OpenAI is revoking and replacing several macOS code-signing certificates after a compromised version of the popular npm library Axios was executed inside its GitHub Actions build pipeline. While there is no evidence of certificate theft or user data compromise, the company is treating the incident as a serious software supply chain risk and rotating all potentially exposed keys.
How the Axios npm supply chain attack unfolded
The incident stems from a targeted compromise of the widely used HTTP client Axios, distributed via the npm registry. Attackers managed to publish a malicious release (Axios 1.14.1) that executed an obfuscated postinstall script named setup.js whenever the package was installed.
This script acted as a dropper, selecting and deploying different payloads depending on the victim’s operating system — macOS, Windows, or Linux. Such OS-aware behavior is typical of advanced supply chain attacks aiming to maximize impact across heterogeneous environments.
According to the investigation, threat actors focused on one of the Axios maintainers and relied heavily on social engineering. The operation, attributed to the North Korea–linked group UNC1069, reportedly involved a fake video call and a staged “technical issue” that tricked the developer into installing malicious software. With the maintainer’s account compromised, the attackers were able to push trojanized versions of Axios directly to the official npm repository.
Malicious Axios package in OpenAI’s GitHub Actions pipeline
Execution in a privileged CI/CD environment
OpenAI confirms that the compromised Axios version was pulled into an automated build process using GitHub Actions. This CI/CD workflow ran with elevated privileges and had access to sensitive build artifacts, including macOS code-signing certificates used for:
- ChatGPT Desktop for macOS
- Codex and Codex CLI
- Atlas
Investigators found no signs that these certificates were accessed, copied, or abused by attackers. All binaries signed with the affected certificate and later notarized by Apple matched legitimate OpenAI macOS applications. Nevertheless, from a security standpoint, the fact that untrusted code executed in a context with access to signing keys constitutes an unacceptable risk to the integrity of the software supply chain.
Why OpenAI is revoking and reissuing macOS signing certificates
OpenAI is treating the exposed certificate as potentially compromised and is proactively revoking and replacing it. This approach aligns with industry best practices: whenever there is reasonable doubt about the confidentiality of a private signing key, conservative key rotation is the only responsible course of action.
Apple’s notarization records confirmed that objects signed with the impacted certificate were legitimate OpenAI apps. However, had attackers obtained the private key, they could have signed malicious macOS binaries and distributed them as if they were official OpenAI applications, potentially bypassing Gatekeeper and other platform defenses.
OpenAI states that older macOS apps signed with the previous certificate will cease to function on 8 May 2026, when the certificate is fully revoked. After that date, macOS will block their execution, treating them as untrusted. Users are therefore expected to migrate to newly signed versions well before this deadline.
Impact on macOS users and unaffected platforms
Based on the current investigation, no compromise of user accounts, internal systems, or intellectual property has been detected. There is also no evidence of unauthorized modifications to OpenAI application code.
The incident is strictly limited to the macOS desktop signing infrastructure. OpenAI notes that:
- Web-based services are unaffected;
- iOS and Android applications are not impacted;
- Windows and Linux clients were not exposed via this issue;
- User passwords, tokens, and API keys were not compromised.
macOS users of OpenAI products should, however, update to the latest versions signed with the new certificates to ensure continued compatibility and reduce any residual risk.
Software supply chain security lessons for CI/CD pipelines
The Axios incident reinforces a broader trend: software supply chain attacks are increasing in both frequency and sophistication. Industry studies, such as Sonatype’s State of the Software Supply Chain, have reported several-hundred-percent growth in such attacks over recent years, largely driven by compromises of open-source ecosystems like npm and PyPI.
From a defensive perspective, the case highlights the need to:
- Enforce strict control over dependencies in CI/CD using lockfiles, version pinning, and trusted internal registries where feasible.
- Apply the principle of least privilege in build pipelines so that only tightly scoped jobs can access secrets such as signing certificates and API tokens.
- Implement regular key and certificate rotation and maintain clear revocation procedures for development and signing infrastructure.
- Introduce additional validation for critical packages from public repositories, including integrity checks, behavioral analysis, and, where possible, software bills of materials (SBOMs).
Organizations that rely heavily on npm or other public registries should consider private mirrors, allowlists for high-impact libraries, and automated monitoring for anomalous dependency behavior. Individual users should keep applications updated, pay attention to operating system warnings about signatures, and install software only from trusted sources.
The OpenAI response to the Axios supply chain compromise demonstrates that even major technology providers can be exposed through third-party dependencies, but also shows how transparent communication, rapid certificate rotation, and stronger CI/CD controls can contain the damage. Systematically hardening build pipelines and elevating supply chain security to a first-class priority is now essential for any organization that develops or deploys software at scale.
