OpenAI Revokes macOS Code Signing Certificate After Axios and Trivy Supply Chain Attacks

CyberSecureFox

OpenAI has disclosed that a compromised Axios npm package was executed inside its macOS application signing pipeline on GitHub Actions. According to the company, no customer data or internal systems were breached, but its macOS code signing certificate is being treated as potentially exposed and is undergoing revocation and rotation — a significant event for both macOS security and the broader software supply chain.

How the Compromised Axios Package Reached OpenAI’s Build Pipeline

In late March, Google’s Threat Intelligence Group (GTIG) linked the compromise of the widely used HTTP client Axios to North Korean threat actor UNC1069. Attackers gained access to an npm maintainer account and published two malicious releases, 1.14.1 and 0.30.4.

These versions silently pulled in a fake dependency, plain-crypto-js, which deployed a cross‑platform backdoor dubbed WAVESHAPER.V2. The malware targeted Windows, macOS, and Linux, turning Axios into a classic example of a software supply chain attack: instead of attacking end products directly, adversaries compromise trusted libraries and dependencies used across thousands of projects.

OpenAI confirmed that on 31 March one of its GitHub Actions workflows for macOS builds downloaded and executed Axios version 1.14.1. This workflow had access to the code signing certificate and notarization assets used to sign and notarize ChatGPT Desktop, Codex, Codex CLI, and Atlas applications for macOS.

Internal analysis led OpenAI to assess that the private key was likely not exfiltrated, citing the sequence of steps in the job, the timing of when the certificate was injected, and other technical constraints. Nevertheless, following a conservative “assume breach” posture, the organization is handling the certificate as compromised.

Revocation of OpenAI’s macOS Code Signing Certificate and User Impact

OpenAI is now performing a full revocation and rotation of its macOS code signing certificate. As a result, legacy desktop clients signed with the old certificate will lose support and update capability, and from 8 May 2026 they will be blocked by macOS security mechanisms such as Gatekeeper by default when downloaded or launched.

In coordination with Apple, OpenAI is ensuring that software signed with the old certificate can no longer obtain new notarization. During a transitional 30‑day window, users are urged to upgrade to versions signed with the new certificate to avoid interruptions and security warnings.

The risk, had the certificate been successfully stolen, is clear: attackers could sign malicious binaries so they appear to be legitimate OpenAI software, bypassing many standard trust checks. Even with new notarizations blocked, social engineering remains a concern, as users can still manually override macOS warnings.

Trivy, TeamPCP and CVE‑2026‑33634: A Wider Supply Chain Campaign

The Axios incident is only one part of a broader campaign targeting open source and DevOps tooling. A parallel attack focused on the popular vulnerability scanner Trivy, maintained by Aqua Security, and has been attributed to cybercriminal group TeamPCP (UNC6780).

By inserting malicious code into Trivy’s supply chain, attackers enabled large‑scale theft of SANDCLOCK credentials. These stolen secrets were then used to compromise multiple npm packages and propagate a self‑spreading worm named CanisterWorm. The same credentials later facilitated injection of malicious code into GitHub Actions workflows at Checkmarx and the release of trojanized LiteLLM and Telnyx packages to the Python Package Index (PyPI).

Research by Trend Micro highlights rapidly evolving attacker TTPs: moving from simple Base64‑encoded payloads in CI pipelines to steganography in WAV audio files, combined Linux and Windows targeting, and strong persistence on Windows. A malicious Telnyx SDK for Windows, for example, deployed a renamed msbuild.exe that extracted a DonutLoader stub from a PNG image, which then pulled down a fully featured trojan and a beacon associated with the AdaptixC2 framework.

The campaign has been assigned CVE‑2026‑33634 and added to the Known Exploited Vulnerabilities catalog by the U.S. Cybersecurity and Infrastructure Security Agency (CISA). U.S. federal agencies were ordered to implement mitigation measures by 9 April 2026, underscoring the severity of the threat.

Scale estimates from independent analysis are sobering. GitGuardian reports that the malicious trivy-action GitHub Actions workflow ran in at least 474 public repositories, while roughly 1,750 Python packages automatically pulled infected dependencies. Google assesses that these Axios and Trivy attacks have likely exposed “hundreds of thousands of secrets”, creating fuel for future supply chain intrusions, SaaS compromises, extortion, and cryptocurrency theft.

Why Attackers Target Security Tools and CI/CD Pipelines

Recent campaigns show a deliberate focus on high‑privilege components — vulnerability scanners, CI/CD systems, package registries, and AI infrastructure. As FBI cyber division representative Brett Leatherman notes, compromising security tooling grants attackers direct paths into the most sensitive environments, because these tools are inherently trusted and broadly permissioned.

This aligns with guidance from Docker CISO Mark Lechner that in modern DevOps environments, “trust must be explicitly verified, not assumed”. In practice, this means continuously validating every dependency, tool, and pipeline step, rather than relying on reputation or default settings.

Practical Steps to Strengthen Software Supply Chain Security

Harden Dependencies and Build Infrastructure

Organizations should prioritize verified base images and trusted registries over random community images, and adopt pinned dependency versions instead of mutable latest tags that can quietly change. Maintaining a Software Bill of Materials (SBOM) for critical applications helps teams quickly assess exposure when incidents such as Axios or Trivy compromises arise.

Secrets used in CI/CD — tokens, keys, and credentials — should be short‑lived, scoped to least privilege, and frequently rotated. Isolated or dedicated CI runners per project, combined with default‑deny egress policies from build jobs, significantly limit the blast radius of a compromised dependency. Continuous monitoring for anomalous GitHub Actions or other pipeline behavior is equally important.

Detect Secrets Exposure and Pipeline Abuse Early

Automated secret scanning across repositories and CI logs (using tools such as GitGuardian or Gitleaks) is now a baseline requirement. Teams should enforce provenance checks on open source dependencies, track advisories related to CVE‑2026‑33634 and similar campaigns, and rapidly map affected components when new supply chain incidents are disclosed.

Assessments from Mandiant (Google) indicate that supply chain attacks are already “off the charts,” prompting many defenders to establish dedicated projects for impact analysis, remediation, and DevSecOps hardening. The OpenAI, Axios, and Trivy incidents confirm that the primary risk surface has shifted to automation layers — GitHub Actions, CI/CD pipelines, dependency managers, and scanners. Organizations that rigorously inventory their software supply chain, instrument it with continuous controls, and treat every automated step as a potential attack vector will be far better positioned to withstand the next wave of supply chain attacks.

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.