OpenAI hat Details zu einem Sicherheitsvorfall veröffentlicht, bei dem ein kompromittiertes npm-Paket (Axios) in einem GitHub-Actions-Workflow für die Signierung von macOS-Anwendungen ausgeführt wurde. Nach aktuellem Stand wurden weder Kundendaten noch interne Systeme kompromittiert. Dennoch stuft OpenAI das betroffene Code-Signing-Zertifikat als potenziell verloren ein und leitet einen vollständigen Rückruf und Austausch des Zertifikats ein.
Wie das kompromittierte npm-Paket Axios in die OpenAI-Lieferkette gelangte
Ende März führte Googles Threat Intelligence Group (GTIG) den Angriff auf das weit verbreitete HTTP-Client-Paket Axios auf die nordkoreanische Gruppe UNC1069 zurück. Angreifer erhielten Zugriff auf das npm-Maintainer-Konto und veröffentlichten zwei manipulierte Versionen – 1.14.1 und 0.30.4 – im offiziellen npm-Repository.
In diese Versionen wurde eine gefälschte Abhängigkeit namens plain-crypto-js eingebettet, die einen plattformübergreifenden Backdoor WAVESHAPER.V2 nachlädt. Der Schadcode zielte auf Windows, macOS und Linux und ist ein typisches Beispiel für einen Supply-Chain-Angriff auf die Software-Lieferkette, bei dem nicht das Endprodukt, sondern vertrauenswürdige Komponenten und Abhängigkeiten attackiert werden.
OpenAI bestätigte, dass am 31. März ein GitHub-Actions-Workflow für den Build- und Signierprozess von macOS-Anwendungen die manipulierte Axios-Version 1.14.1 heruntergeladen und ausgeführt hat. Dieser Pipeline-Job besaß Zugriff auf das macOS-Code-Signing-Zertifikat und die Notarisierungsartefakte, die zur Signierung von ChatGPT Desktop, Codex, Codex CLI und Atlas genutzt werden.
Interne forensische Analysen deuten darauf hin, dass der private Schlüssel des Zertifikats mit hoher Wahrscheinlichkeit nicht exfiltriert wurde. Ausschlaggebend sind dabei die genaue Abfolge der Pipeline-Schritte, der Zeitpunkt der Zertifikatsinjektion und weitere technische Begrenzungen. Dennoch folgt OpenAI dem Prinzip des Worst-Case-Scenarios und behandelt das Zertifikat als kompromittiert.
Rückruf des macOS-Zertifikats: Auswirkungen auf OpenAI-Nutzer
Im Zuge des Vorfalls führt OpenAI eine vollständige Rotation des macOS-Code-Signing-Zertifikats durch. Ältere Versionen der Desktop-Clients werden dadurch nicht mehr unterstützt und nicht mehr aktualisiert. Ab dem 8. Mai 2026 werden Anwendungen, die noch mit dem alten Zertifikat signiert sind, von den integrierten Schutzmechanismen von macOS standardmäßig blockiert.
Gemeinsam mit Apple sorgt OpenAI dafür, dass Software, die mit dem alten Zertifikat signiert ist, keine neue Notarisierung mehr erhalten kann. Nutzerinnen und Nutzer haben einen Übergangszeitraum von rund 30 Tagen, um auf Versionen mit neuem Zertifikat zu aktualisieren, um Unterbrechungen im Betrieb zu vermeiden.
Das zentrale Risiko eines erfolgreich kompromittierten Code-Signing-Zertifikats liegt darin, dass Angreifer Malware als legitime OpenAI-Software tarnen könnten. Zwar verhindert der Stopp neuer Notarisierungen einen Großteil solcher Szenarien, doch bleibt ein Restrisiko: macOS-Warnungen können manuell übergangen werden, wenn Anwender diese ignorieren.
Verknüpfte Kampagne: Trivy, TeamPCP und CVE‑2026‑33634
Der Axios-Vorfall ist Teil einer umfassenderen Offensive gegen die Open-Source-Sicherheits- und DevOps-Ökosysteme. Parallel wurde die Lieferkette des populären Schwachstellen-Scanners Trivy (Aqua Security) durch die Gruppe TeamPCP (UNC6780) kompromittiert.
Durch manipulierten Code im Trivy-Ökosystem setzten die Angreifer eine massive Geheimnisexfiltration (SANDCLOCK) um: erbeutete Zugangsdaten wurden genutzt, um npm-Pakete zu kompromittieren und den sich selbst verbreitenden Wurm CanisterWorm zu verteilen. Dieselben Secrets dienten anschließend dazu, GitHub-Actions-Workflows u.a. von Checkmarx zu manipulieren und schädliche Versionen der Python-Pakete LiteLLM und Telnyx in PyPI einzuschleusen.
Analysen von Trend Micro zeigen eine schnelle Weiterentwicklung der Taktiken, Techniken und Prozeduren (TTPs): von einfachen Base64-Skripten in Pipelines hin zu Steganographie in WAV-Dateien und gleichzeitigem Angriff auf Linux- und Windows-Umgebungen. Auf Windows-Systemen lud eine manipulierte Telnyx-SDK-Version die legitime msbuild.exe, die aus einem PNG-Bild den Loader DonutLoader extrahierte und schließlich einen vollwertigen Trojaner und einen AdaptixC2-Beacon nachlud.
Die Kampagne wird unter der Kennung CVE‑2026‑33634 geführt und ist im Known Exploited Vulnerabilities (KEV)-Katalog der US-Cyberbehörde CISA gelistet. Bundesbehörden in den USA wurden verpflichtet, bis zum 9. April 2026 geeignete Abwehrmaßnahmen umzusetzen – ein Indikator für die hohe Priorität dieser Vorfälle.
Dimension des Schadens: Hunderte Tausend Secrets und tausende Projekte betroffen
Die Reichweite der Supply-Chain-Angriffe ist erheblich. Laut GitGuardian wurde der manipulierte GitHub-Actions-Workflow trivy-action mindestens in 474 öffentlichen Repositorien ausgeführt. Zudem zogen etwa 1750 Python-Pakete automatisch infizierte Abhängigkeiten nach.
Google schätzt, dass durch die kombinierten Angriffe auf Axios und Trivy „hunderttausende gestohlene Secrets“ im Umlauf sein könnten. Diese vertraulichen Informationen – von API-Tokens über Cloud-Zugangsdaten bis hin zu CI/CD-Schlüsseln – eröffnen Angreifern vielfältige Folgeoptionen: weitere Supply-Chain-Angriffe, Kompromittierung von SaaS-Diensten, Erpressung und Diebstahl von Krypto-Assets.
Warum Sicherheitswerkzeuge zum bevorzugten Ziel für Supply-Chain-Angriffe werden
Besonders kritisch ist, dass sich die Angreifer gezielt auf Sicherheits- und DevOps-Werkzeuge mit hohen Privilegien konzentrieren: Schwachstellen-Scanner, CI/CD-Pipelines, Paketmanager und KI-Infrastruktur. Wie Vertreter der Cyber-Division des FBI betonen, erhalten diese Werkzeuge per Design weitreichende Zugriffsrechte auf sensible Umgebungen und sind daher ein attraktives Einfallstor.
Der CISO von Docker, Mark Lechner, formuliert es treffend: In modernen DevOps-Umgebungen muss „Vertrauen explizit überprüfbar und nicht implizit vorausgesetzt“ sein. Praktisch bedeutet dies unter anderem den Einsatz verifizierter Basis-Images statt beliebiger Community-Images, das konsequente Verwenden fixierter Versionsstände (pinned versions) anstelle schwebender latest-Tags, den Einsatz minimaler, kurzlebiger Secrets sowie isolierter CI-Runner, die nicht unkontrolliert zwischen Projekten geteilt werden.
Die Vorfälle um Axios, Trivy und CVE‑2026‑33634 verdeutlichen, dass Automatisierung die zentrale Angriffsfläche in der Software-Lieferkette geworden ist: GitHub Actions, CI/CD-Pipelines, Dependency-Manager und Code-Scanner werden gleichermaßen ins Visier genommen. Organisationen sollten daher ihre Lieferketten systematisch inventarisieren, kontinuierliches Secrets-Scanning etablieren, die Nutzung von Open-Source-Abhängigkeiten über SBOMs (Software Bill of Materials) nachhalten und Anomalien in Build-Pipelines laufend überwachen.
Für Sicherheits- und Entwicklungsteams bedeutet dies, dedizierte Supply-Chain-Security-Projekte einzuplanen: von der Bewertung der eigenen Exponierung über das Schließen identifizierter Lücken bis hin zur Verstärkung von DevSecOps-Prozessen. Wer jetzt in Transparenz, überprüfbares Vertrauen und robuste Automatisierung investiert, reduziert signifikant das Risiko, von der nächsten Welle von Supply-Chain-Angriffen überrascht zu werden – und schützt zugleich Kunden, Partner und die eigene Marke.
