OpenAI erneuert sein macOS-Signaturzertifikat, nachdem ein manipulierter Axios-Build in der App-Signierungspipeline gelaufen ist

Eine Frontend-HTTP-Bibliothek landete im Code-Signing-Job

Axios ist einer der meistgenutzten HTTP-Clients im JavaScript-Ökosystem – die Art von Abhängigkeit, die still im transitiven Abhängigkeitsbaum unzähliger Frontend- und Node-Tooling-Projekte sitzt. Am 31. März 2026 (UTC) wurde eine bösartige Version, 1.14.1, als Teil eines größeren Supply-Chain-Angriffs veröffentlicht.

Das Besondere an OpenAIs Offenlegung ist, wo diese Bibliothek lief. Der kompromittierte Axios-Build wurde von einem GitHub-Actions-Workflow geladen und ausgeführt, der im macOS-App-Signierungsprozess von OpenAI verwendet wird – demselben Job, der Zugriff auf Zertifikat und Notarisierungsmaterial für ChatGPT Desktop, Codex, Codex CLI und Atlas hatte. Ein JavaScript-Paket, das eigentlich für Web-Requests gedacht war, befand sich plötzlich in unmittelbarer Nähe zu den Schlüsseln, die macOS mitteilen, dass diese Apps tatsächlich von OpenAI stammen.

Die unbequeme Lehre daraus: Eine Signierungspipeline ist nur so vertrauenswürdig wie jedes Paket, das sie beim Build installiert. Das Zertifikat ist das Kronjuwel – der Workflow drumherum erbte jedoch die Risikofläche des gesamten npm-Abhängigkeitsgraphen.

Zwei konkrete Fehlkonfigurationen, die OpenAI benennt

OpenAI äußert sich ungewöhnlich präzise zur Ursache. Der Workflow referenzierte die betroffene Action über ein nicht fixiertes Tag statt über einen gepinnten Commit-Hash, und es war kein minimumReleaseAge für neue Pakete konfiguriert.

Die betreffende Action verwendete ein nicht fixiertes Tag anstelle eines konkreten Commit-Hashes und hatte kein konfiguriertes minimumReleaseAge für neue Pakete.Montana Labs

Beides ist jedem vertraut, der CI-Systeme betreut. Ein nicht fixiertes Tag bedeutet, dass der Workflow stillschweigend akzeptiert, worauf der Maintainer – oder ein Angreifer, der den Maintainer kompromittiert hat – dieses Tag umleitet. Ein minimumReleaseAge hätte ein Quarantänefenster erzwungen und Pakete abgelehnt, die zu kurz zuvor veröffentlicht wurden, um geprüft zu sein; wäre es gesetzt gewesen, hätte die bösartige Version vom 31. März möglicherweise nie Verwendung gefunden. Das sind keine exotischen Schutzmaßnahmen, sondern die Standardempfehlungen zum Pinning und verzögerten Einspielen von Abhängigkeiten – hier angewendet auf eine Pipeline, deren Explosionsradius zufällig ein Signaturzertifikat war.

Die Behebung verlagert die Kosten auf den Client, nicht auf den Server

OpenAI kam zu dem Schluss, dass das Zertifikat wahrscheinlich nicht exfiltriert wurde, gestützt auf das Timing der Payload, die Reihenfolge der Zertifikatseinschleusung und weitere mildernde Faktoren. Es fand keine Hinweise auf missbrauchte Notarisierung, keine unautorisierten Änderungen an veröffentlichter Software und keine Kompromittierung von Nutzerdaten oder API-Schlüsseln. Trotzdem behandelt OpenAI das Zertifikat als kompromittiert und erneuert es.

Diese Entscheidung verlagert die Behebung auf jeden macOS-Nutzer. Neue, mit dem frischen Zertifikat signierte Builds erscheinen als früheste unterstützte Versionen – ChatGPT Desktop 1.2026.051, Codex App 26.406.40811, Codex CLI 0.119.0 und Atlas 1.2026.84.2 – und nach dem 8. Mai 2026 könnten ältere Versionen komplett funktionsuntüchtig werden, sobald das alte Zertifikat vollständig widerrufen ist.

Das gestufte Vorgehen ist bewusst gewählt. OpenAI hat bereits neue Notarisierungen mit dem alten Zertifikat blockiert, sodass eine damit gefälschte, signierte App standardmäßig an Gatekeeper scheitern würde, sofern ein Nutzer die Schutzmaßnahmen nicht manuell umgeht. Das 30-tägige Fenster vor dem vollständigen Widerruf soll den In-App-Updatern Zeit geben, aufzuholen, und OpenAI erklärt, den Widerruf zu beschleunigen, sollte während dieses Zeitraums bösartige Aktivität festgestellt werden.

Was eine kompromittierte Signierungspipeline für Teams bedeutet, die Desktop-Clients ausliefern

Die sichtbare Oberfläche dieser Produkte ist ein Chatfenster und ein Code-Editor, doch der Vertrauensanker ist ein Zertifikat, das aus einem Build-Job stammt. Dieser Vorfall lässt die Trennung zwischen Frontend-Abhängigkeiten und Produktionssicherheit verschwimmen: Ein Paket, das eigentlich nur Tooling unterstützen sollte, befand sich im selben Ausführungskontext wie das Signaturmaterial, und ein einziges vergiftetes Release erzwang eine Zertifikatserneuerung, die jeder Mac-Nutzer von vier verschiedenen Apps zu spüren bekam.

Für alle, die ähnliche Pipelines betreiben, sind die konkreten Lehren genau die, die OpenAI selbstkritisch benennt – Actions auf Commit-Hashes pinnen, ein Release-Age-Quarantänefenster für neue Pakete erzwingen und den Workflow, der Signaturschlüssel berührt, als Umgebung mit höchsten Privilegien behandeln, getrennt von gewöhnlichen Abhängigkeitsinstallationen. Die Zertifikatserneuerung und das erzwungene Client-Update waren die teure Wiederherstellung; die günstige Prävention wären zwei Zeilen CI-Konfiguration gewesen.