For AI agents: the public content index is available at https://we0.ai/llms.txt, and the English article bundle is available at https://we0.ai/llms-full.txt.
For AI agents: the complete content index is available at https://we0.ai/llms.txt, the full English article bundle is available at https://we0.ai/llms-full.txt, and this page is available as Markdown at https://we0.ai/de/articles/openai-codex-security-issues-curated-plug-d8ba6dc7.md.
OpenAI nutzt Codex Security und Patch the Planet, um Software-Schwachstellen mithilfe von KI zu finden. Gleichzeitig war Codex selbst von Sc...

OpenAI hat im gesamten Jahr 2026 daran gearbeitet, KI noch stärker in die Softwaresicherheit zu integrieren.
Im März brachte das Unternehmen Codex Security als Research Preview auf den Markt. Dabei handelt es sich um einen Application-Security-Agenten, der Schwachstellen finden, validieren und bei ihrer Behebung helfen soll. Im Juni stellte OpenAI Patch the Planet vor, eine Daybreak-Initiative mit Trail of Bits, die Open-Source-Maintainer dabei unterstützen soll, Sicherheitsprobleme zu finden und zu beheben. Ende Juli veröffentlichte OpenAI außerdem die Open-Source-Codex-Security-CLI und das TypeScript-SDK.
Dadurch ist die Sicherheitsgeschichte rund um Codex besonders relevant.
Codex ist nicht nur ein Modell zur Codegenerierung. Es handelt sich um einen lokal und cloudbasiert verbundenen Coding-Agenten, der Repositories lesen, Dateien bearbeiten, Tools aufrufen, Befehle ausführen, Plugins laden, Verbindungen zu MCP-Diensten herstellen und in Entwicklungsumgebungen arbeiten kann, die häufig Quellcode und Zugangsdaten enthalten.
Im September hob ein Bericht von BAAI/New Zhiyuan eine neue, 360 Tulongfeng zugeschriebene Sicherheitsbehauptung zu Codex hervor. Dem Bericht zufolge betraf das Problem den Synchronisierungspfad für kuratierte Git-Plugins von Codex und konnte die Genehmigungsgrenze umgehen, die Nutzer normalerweise vor sensiblen Aktionen erwarten.
Diese konkrete neue 360-Feststellung wurde nicht von einem öffentlichen OpenAI-Hinweis oder einem ausführlichen technischen Bericht begleitet, der unabhängig belegt, dass es sich um einen eigenständigen Zero-Day handelt. Das im Artikel beschriebene allgemeine Risiko ist jedoch real: Öffentliche Berichte zu Codex hatten bereits gezeigt, dass die Start-Synchronisierung kuratierter Plugins außerhalb der Modellsandbox ausgeführt werden konnte und unter bestimmten Git-Umgebungsbedingungen auf das Repository des Nutzers statt auf den Plugin-Cache zugreifen konnte.
Der Unterschied ist wichtig. Dieser Artikel bewahrt die Struktur der ursprünglichen Geschichte, trennt jedoch bestätigte öffentliche Vorfälle, von Forschern gemeldete Ergebnisse und Herstellerangaben.

OpenAI stellte Codex Security am 6. März 2026 vor.
Das Produkt soll Kontext zu einer Codebasis aufbauen, Sicherheitsprobleme identifizieren, die Relevanz eines Befunds validieren und Korrekturen vorschlagen. Anders als ein einfacher Musterscanner positioniert OpenAI Codex Security als agentisches Sicherheitssystem, das über ein gesamtes Projekt hinweg Schlussfolgerungen ziehen und die Zahl der Fehlalarme reduzieren kann.
Später weitete OpenAI diese Initiative mit Patch the Planet aus.
Die Initiative verbindet KI-gestützte Schwachstellenforschung mit menschlicher Prüfung, damit Maintainer überprüfte Befunde erhalten, die durch Patches und Tests ergänzt werden können.
Die grundlegende Botschaft ist klar: KI kann sowohl die Geschwindigkeit der Softwareentwicklung als auch die Geschwindigkeit der Schwachstellensuche erhöhen. Deshalb benötigen defensive Teams schnellere Möglichkeiten, Code zu prüfen und Probleme zu beheben.
Die vom Ausgangsartikel hervorgehobene Ironie besteht darin, dass dieselbe Art von Coding-Agent-Infrastruktur, die zum Auffinden der Fehler anderer eingesetzt wird, selbst zu einem wertvollen Ziel für Sicherheitsforscher geworden ist.
Der Ausgangsartikel schreibt eine neu entdeckte Codex-Schwachstelle dem Tulongfeng-System von 360 zu und bringt das Problem mit dem Mechanismus zur Synchronisierung kuratierter Git-Plugins von Codex in Verbindung.
Im normalen Betrieb stützt sich Codex auf mehrere Sicherheitskontrollen:
Das Risiko entsteht offenbar dann, wenn Start- oder Infrastrukturcode außerhalb derselben Sandbox ausgeführt wird, die für vom Modell gesteuerte Befehle verwendet wird.
Diese Unterscheidung ist bereits in öffentlichen Codex-Issue-Berichten zu erkennen.
Ein GitHub-Issue vom Juli dokumentierte einen Fall, in dem die Start-Synchronisierung kuratierter Plugins Git-Befehle ausführte, ohne lokale GIT_*-Umgebungsvariablen des Repositorys vollständig zu isolieren. Wenn Codex innerhalb bestimmter Git-Hook- oder Worktree-Kontexte gestartet wurde, konnte die Synchronisierung auf das Repository des Nutzers statt auf den vorgesehenen Plugin-Cache zugreifen.
Der Verfasser wies ausdrücklich darauf hin, dass --sandbox read-only das Verhalten nicht unterband, weil die Synchronisierung zur Codex-Startinfrastruktur gehörte und kein vom Modell innerhalb der Sandbox ausgeführter Befehl war.

OpenAI integrierte am 24. Juni 2026 eine Korrektur mit dem Titel „Isolate curated plugin sync Git environment“. Öffentliche Issues zu den betroffenen Versionen 0.142.x und frühen 0.143-Builds zeigten, dass die Korrektur zunächst auf main vorhanden war, bevor sie stabile Releases erreichte.
Diese öffentliche Historie stützt die zentrale Aussage des Artikels: Sicherheitsgrenzen eines Agenten müssen auch dessen eigene Infrastruktur abdecken und nicht nur die vom Modell direkt angeforderten Shell-Befehle.
Weniger klar ist, ob die Tulongfeng zugeschriebene Behauptung vom September einen separaten Exploit-Pfad über das zuvor öffentlich dokumentierte Problem mit der Isolierung der Start-Synchronisierung hinaus darstellt. Ohne einen öffentlichen Hinweis, eine CVE oder eine technische Ausarbeitung von OpenAI oder 360 wird diese Version die Behauptung eines „neuen Zero-Days“ nicht als unabhängig bestätigte Tatsache darstellen.
Ein vertrautes Sicherheitsmodell für Codex sieht folgendermaßen aus:
Auch die aktuellen Leitlinien von OpenAI zur Agentensicherheit folgen diesem allgemeinen Prinzip: Risikoreiche Seiteneffekte sollten unabhängig begrenzt und bei Bedarf für eine ausdrückliche menschliche Prüfung angehalten werden.
Das Problem besteht darin, dass ein Berechtigungsdialog eine Aktion nur dann schützen kann, wenn die Aktion tatsächlich den Codepfad durchläuft, der den Dialog erzwingt.
Wenn ein Hintergrund-Updater, eine Plugin-Synchronisierung, ein Hilfsprozess oder ein anderes vertrauenswürdiges Subsystem außerhalb dieses Pfads arbeitet, ist die sichtbare Genehmigungsoberfläche möglicherweise überhaupt nicht die relevante Sicherheitsgrenze.
Dies ist eine der wichtigsten Erkenntnisse aus den Codex-Schwachstellenberichten von 2026.
Das Bedrohungsmodell für ein KI-Coding-Tool lautet nicht mehr nur:
„Wird das Modell darum bitten, einen gefährlichen Befehl auszuführen?“
Es lautet auch:
„Welche Teile der Agentenplattform können Dateien ändern, Prozesse starten, Code abrufen, Plugins laden, Zugangsdaten lesen oder mit Git interagieren, bevor oder außerhalb des normalen Genehmigungsablaufs des Modells?“
Der Ausgangsartikel veranschaulicht die möglichen Auswirkungen anhand eines Szenarios aus der Software-Lieferkette.
Dafür muss Malware nicht über einen offensichtlich bösartigen Download eintreffen.
Eine realistischere Abfolge sieht so aus:
Deshalb sind Entwickler-Workstations besonders wertvolle Ziele.
Sie können Folgendes enthalten:
Die erste kompromittierte Maschine muss nicht das eigentliche Ziel des Angreifers sein.
Das Ziel kann vielmehr das Vertrauen sein, das an die Identität des Entwicklers und die Release-Pipeline gebunden ist.
Das ist das entscheidende Merkmal eines Risikos in der Software-Lieferkette: Der Angreifer versucht, einen vertrauenswürdigen Softwarepfad in den Verteilungsmechanismus zu verwandeln.
Die Geschichte rund um kuratierte Plugins ist Teil einer umfassenderen Folge von Sicherheitsforschungen zu KI-Coding-Agenten.
Der Ausgangsartikel fasst mehrere Vorfälle aus dem Jahr 2026 zusammen, von denen die meisten unabhängig überprüft werden können.
Pwn2Own Berlin 2026 führte eine eigene Kategorie Coding Agent ein, in der OpenAI Codex, Anthropic Claude Code und Cursor als Ziele vertreten waren.
Die offiziellen Ergebnisse des Zero Day Initiative für den ersten Tag zeigen, dass Compass Security OpenAI Codex mithilfe eines Problems der Klasse CWE-150 erfolgreich ausnutzte und 40.000 US-Dollar sowie vier Master-of-Pwn-Punkte erhielt.
Doyensec demonstrierte ebenfalls einen Exploit gegen Codex. Das Ergebnis wurde jedoch als Kollision eingestuft, weil der Hersteller den zugrunde liegenden Fehler bereits kannte.
Die Veranstaltung endete insgesamt mit 47 einzigartigen Zero-Day-Schwachstellen und Preisgeldern in Höhe von 1.298.250 US-Dollar über alle Kategorien hinweg.

Pwn2Own ist als Referenz besonders hilfreich, weil die Regeln für Coding-Agenten einfache Jailbreaks und unsichere Modi ausschlossen. Für einen erfolgreichen Beitrag musste eine relevante Sicherheitsgrenze über einen üblichen Coding-Agent-Workflow hinweg überschritten werden.
Am 12. August erklärte 360 öffentlich, dass sein KI-Sicherheitssystem Tulongfeng sechs hochwertige Sicherheitslücken in OpenAI Codex gefunden habe.
Laut der Mitteilung von 360 umfassten die Ergebnisse Hochrisikofälle, die zu einer entfernten Ausführung beliebigen Codes führen und Codex-Vertrauensabfragen umgehen konnten, wenn Nutzer nicht vertrauenswürdige Projektverzeichnisse öffneten.
Die Offenlegung wurde von mehreren chinesischen Medien und von Xinhua über einen syndizierten Bericht wiederholt.
Die detaillierten technischen Berichte und CVE-ähnlichen Kennungen für alle sechs Befunde wurden jedoch in den für diesen Artikel geprüften Quellen nicht veröffentlicht.
Die korrekte Formulierung lautet daher:
360 berichtet, dass Tulongfeng sechs hochwertige Codex-Schwachstellen gefunden habe, darunter Fälle mit Auswirkungen bis hin zur entfernten Codeausführung.
Das ist etwas anderes als eine unabhängige Validierung aller sechs Exploit-Ketten anhand öffentlich zugänglicher technischer Materialien.
Der Sicherheitsforscher Oren Yomtov von Accomplish meldete OpenAI am 12. August zwei Codex-Sandbox-Escapes.
Die Forscher nannten sie Overpatch und Heapjack.
Overpatch betraf den Patching-Pfad der Open-Source-Codex-CLI und konnte die vorgesehene Grenze des Arbeitsbereichs mit Schreibzugriff verlassen.
Heapjack zielte auf einen von Codex Desktop verwendeten JavaScript-Hilfsprozess. Nach Angaben der Forscher konnte der Angriff in einer nicht sandboxgeschützten Befehlsausführung enden, selbst wenn Codex im schreibgeschützten Modus betrieben wurde.
Die Forscher geben an, dass OpenAI beide Probleme innerhalb von acht Tagen behoben hat.
Ihre veröffentlichten Hinweise zur Behebung empfehlen Nutzern, auf folgende Versionen zu aktualisieren:
| Problem | Von Forschern gemeldete behobene Version |
|---|---|
| Overpatch | Codex CLI 0.149.0 oder höher |
| Heapjack | Codex-Desktop-Build 26.818.21641 oder höher |
Diese Versionsnummern stammen aus der Offenlegung der Forscher und nicht aus einem separaten Sicherheitshinweis von OpenAI.
AIR Security legte Plugin4Shell am 17. September offen.
Die Schwachstelle betraf die Logik zur Installation und Aktualisierung von Plugins in folgenden Produkten:
AIR beschrieb das Problem als Zero-Click-Pfad zur entfernten Codeausführung. Ursache war, dass nicht überprüft wurde, ob der nach der Plugin-Installation ausgecheckte Code tatsächlich dem Commit entsprach, auf den der Marketplace das Plugin festlegen wollte.
Da Codex und Claude Code installierte Plugins automatisch aktualisieren konnten, konnte ein zuvor vertrauenswürdiges Plugin zu einem Lieferkettenpfad werden, ohne dass der Nutzer erneut klicken musste.

AIR zufolge behob OpenAI die Schwachstelle in Codex 0.146.0.
Plugin4Shell ist wichtig, weil es sich nicht um ein Versagen des Modellverhaltens handelte. Es war ein klassischer Designfehler der Software-Lieferkette in der Verteilungsschicht rund um den Agenten.
Die Codex-Befunde von 2026 haben nicht alle dieselbe Ursache.
Einige betreffen Sandbox-Grenzen.
Andere betreffen Hilfsprozesse.
Weitere stehen mit der Verarbeitung der Git-Umgebung in Verbindung.
Andere wiederum betreffen die Plugin-Verteilung.
Gemeinsam ist ihnen jedoch eine erweiterte Trusted Computing Base.
Ein moderner Coding-Agent ist nicht nur:
Nutzeraufforderung -> Modell -> Antwort
Er ähnelt eher:
Nutzer
-> Modell
-> Agenten-Harness
-> Tool-Router
-> Shell
-> Dateisystem
-> Git
-> Plugin-Manager
-> MCP-Dienste
-> Zugangsdaten
-> Netzwerk
-> CI/CD
Jede Schicht bringt nützliche Fähigkeiten mit.
Beschreibe deine Idee einmal, und We0 AI erstellt eine Showcase-Website, Seiten und ein CMS und hilft nach dem Launch bei Kunden und Traffic.
Eine komplette Projektgeneration zur kostenlosen Registrierung
Am besten geeignet, um einen vollständigen Generierungsablauf auszuprobieren und schnell einen ersten Projektentwurf zu sehen.
Jede Schicht kann jedoch auch eine neue Sicherheitsgrenze einführen.
Deshalb ist „das Modell ist sandboxgeschützt“ allein kein vollständiges Sicherheitsargument.
Die Agentenplattform muss außerdem nachweisen, dass Updater, Plugin-Loader, Dateieditor, Terminalbrücke, Netzwerkproxy, Hilfs-Daemons und Zugangsdatenpfade denselben Sicherheitsannahmen folgen.
Die übergeordnete Aussage des Ausgangsartikels lautet, dass KI beide Seiten der Softwaresicherheit beschleunigt.
Auf der Entwicklungsseite können Coding-Agenten Funktionen, Tests, Infrastruktur, Integrationen und ganze Projekte deutlich schneller als in herkömmlichen manuellen Arbeitsabläufen erstellen.
Dadurch steigt die Menge des neu produzierten Codes.
Auf der defensiven Seite sind Systeme wie Codex Security und Tulongfeng darauf ausgelegt, große Codebasen zu analysieren und Schwachstellen im Maßstab von Maschinen zu finden.
Dadurch steigt die Geschwindigkeit, mit der alte und neue Schwachstellen entdeckt werden können.
Beide Entwicklungen verstärken sich gegenseitig.
Mehr Code schafft eine größere Angriffsfläche.
Bessere Sicherheitsautomatisierung entdeckt mehr von dieser Angriffsfläche.
Das Ergebnis ist nicht zwangsläufig ein weniger sicheres Software-Ökosystem. Es bedeutet jedoch, dass Sicherheitsprüfungen mit einer Geschwindigkeit arbeiten müssen, die näher an der Geschwindigkeit KI-gestützter Entwicklung liegt.
Coding-Agenten nehmen im Software-Stack eine ungewöhnliche Position ein.
Sie befinden sich vorgelagert zu den Anwendungen, die Nutzer später installieren.
Sie können Zugriff auf Folgendes haben:
Ein Fehler in einem normalen Chatbot kann eine falsche Antwort erzeugen.
Ein Fehler in einem Coding-Agenten kann dagegen eine geänderte Datei, einen gestarteten Prozess, ein verändertes Repository, eine offengelegte Zugangsdaten oder einen kompromittierten Build-Pfad zur Folge haben.
Deshalb ähnelt die Sicherheit von Coding-Agenten zunehmend der Endpoint-Sicherheit und der Sicherheit von Software-Lieferketten und nicht nur der Modellsicherheit.
Auch die aktuellen Sandbox-Empfehlungen von OpenAI spiegeln diese Realität wider. Sie empfehlen, Workloads zu isolieren, ausgehenden Netzwerkzugriff einzuschränken, Zugangsdaten zu trennen, Anwendungsschlüssel außerhalb von Agenten-Ausführungsumgebungen zu halten und unabhängige Genehmigungskontrollen für folgenschwere Aktionen einzusetzen.
Das letzte Drittel des Ausgangsartikels konzentriert sich auf 360 Tulongfeng und den Wettlauf zwischen Verteidigern und Angreifern.
Die zentrale Idee ist stichhaltig: Eine Schwachstelle existiert unabhängig davon, ob der Hersteller davon weiß.
Wenn ein Verteidiger sie zuerst findet, besteht die Möglichkeit, das System zu patchen, bevor sich die Ausnutzung verbreitet.
Findet ein Angreifer sie zuerst, kann derselbe Fehler zu einem Sicherheitsvorfall werden.
Das ist das wirtschaftliche Argument für die automatisierte Schwachstellenforschung.
Die Initiativen Codex Security und Patch the Planet von OpenAI basieren auf derselben Annahme, auch wenn sie von einer anderen Organisation stammen.
Ziel ist es, die Entdeckung von Schwachstellen in eine frühere Phase des Softwarelebenszyklus zu verlagern.
360 beschreibt Tulongfeng als ein System zur KI-gestützten Schwachstellenentdeckung, das auf zwei Komponenten basiert:
360 zufolge wurde das Produkt zur Prüfung von Quellcode, Binärdateien, Firmware, Geschäftssystemen und KI-Toolchains eingesetzt.
Das Unternehmen erklärt außerdem, dass Tulongfeng bis Ende August beziehungsweise September 2026 mehr als 10.000 Schwachstellen gefunden habe.
Bei dieser Zahl handelt es sich um eine vom Hersteller gemeldete kumulative Zahl.
Eine Community-Mitteilung von 360 vom 25. August besagte, dass das System mehr als 10.000 Schwachstellen gefunden habe und nahezu 400 Organisationen angebunden worden seien und Sicherheitstests abgeschlossen hätten. Ein späterer Beitrag im September wiederholte die Zahl von mehr als 10.000.
Der Ausgangsartikel behauptet außerdem, dass 260 Befunde von chinesischen Schwachstellenbehörden verifiziert worden seien und nahezu 500 Organisationen angebunden waren. Diese genauen Zahlen konnten in der neuesten für diese Version geprüften 360-Quelle nicht bestätigt werden und werden daher hier nicht als unabhängig verifizierte Angaben wiederholt.
Der Ausgangsartikel beschreibt den Ansatz von Tulongfeng als eine Form rekursiver Verbesserung.
Dabei geht es weniger darum, dass das Basismodell seine eigenen Gewichte umschreibt. Vielmehr wird aus abgeschlossenen Sicherheitsaufgaben ein wiederverwendbarer operativer Erfahrungsspeicher aufgebaut.
Der Ablauf lässt sich wie folgt zusammenfassen:
Dies ähnelt der Art und Weise, wie Sicherheitsteams Playbooks, Exploit-Wissensdatenbanken, Erkennungsregeln und Verfahren zur Reaktion auf Sicherheitsvorfälle aufbauen.
Der Unterschied besteht darin, dass ein Agentensystem diese Erfahrung potenziell mit deutlich höherer Geschwindigkeit und über viele parallele Aufgaben hinweg wiederverwenden kann.
Die Behauptung des Herstellers lautet, dass einzelne Sicherheitsentdeckungen dadurch in eine gemeinsame Fähigkeit des gesamten Agentenschwarms verwandelt werden.
Der Artikel endet mit einem Bild der Lieferkette, das es wert ist, beibehalten zu werden.
Wenn ein Nutzer auf „Aktualisieren“ tippt, kann die betreffende Software folgende Stationen durchlaufen haben:
Jede Stufe übernimmt Vertrauen von der vorherigen Stufe.
KI-Coding-Agenten befinden sich nun am Anfang dieser Kette.
Dadurch werden ihre eigenen Sicherheitskontrollen zu einem Bestandteil des Sicherheitsmodells jeder Anwendung, an deren Erstellung und Veröffentlichung sie mitwirken.
Die praktische Schlussfolgerung lautet nicht, dass Entwickler die Nutzung von Coding-Agenten einstellen sollten.
Vielmehr müssen Coding-Agenten wie leistungsfähige Entwicklungsinfrastruktur behandelt werden.
Sie benötigen ebenso wie jedes andere privilegierte Tool Versionsverwaltung, Isolation, das Prinzip der geringsten Rechte, die Trennung von Geheimnissen, Plugin-Governance, Sicherheitsüberwachung und schnelle Patches.
Auf Grundlage der aktuellen Empfehlungen von OpenAI und der öffentlichen Schwachstellenoffenlegungen von 2026 können Entwickler ihre Risiken mit einigen konkreten Maßnahmen reduzieren.
Bekannte Sicherheitskorrekturen wurden schnell veröffentlicht.
Für die oben behandelten, von Forschern offengelegten Probleme sollten betroffene Nutzer die für Plugin4Shell, Overpatch und Heapjack gemeldeten behobenen Builds überschritten haben.
Gehen Sie nicht davon aus, dass kein Codepfad ausgeführt werden kann, nur weil Sie den Agenten „lediglich etwas gefragt“ haben.
Verwenden Sie bei der Prüfung unbekannter Repositories eine Isolation.
Vermeiden Sie es, hochwertige Cloud-, Paketregistrierungs-, Signatur- und Produktionszugangsdaten direkt einer Agenten-Ausführungsumgebung bereitzustellen.
Erlauben Sie nur die für die Aufgabe erforderlichen ausgehenden Ziele.
Ein Coding-Agent mit beliebigem ausgehendem Netzwerkzugriff und weitreichenden Zugangsdaten hat einen deutlich größeren Schadensradius.
Ein vertrauenswürdiger Agent kann trotzdem über eine nicht vertrauenswürdige Erweiterung oder einen nicht vertrauenswürdigen Update-Kanal kompromittiert werden.
Fixieren, prüfen und aktualisieren Sie Plugins bewusst.
Bei Vorgängen mit hohen Auswirkungen sollten Genehmigungen von einer separaten vertrauenswürdigen Komponente erzwungen werden und nicht ausschließlich von Logik, die in derselben Ausführungsumgebung wie der Agent läuft.
Protokollieren und prüfen Sie:
Die abschließende Antwort des Modells ist nur ein Teil dessen, was der Agent ausgeführt hat.
Codex verwendete einen Startmechanismus, um kuratierte Plugins über Git zu synchronisieren. Öffentliche GitHub-Issues zeigten, dass frühere Versionen lokale Git-Umgebungsvariablen des Repositorys übernehmen und Synchronisierungsvorgänge statt auf dem vorgesehenen Plugin-Cache auf dem Repository des Nutzers ausführen konnten – außerhalb der Modellsandbox.
Der Artikel von BAAI/New Zhiyuan schreibt Tulongfeng von 360 einen neuen Angriffspfad über die Synchronisierung kuratierter Git-Plugins zu. Es wurde jedoch kein öffentlicher Hinweis von OpenAI oder eine ausführliche technische Offenlegung von 360 gefunden, die diese konkrete Behauptung vom September unabhängig als eigenständigen neuen Zero-Day bestätigt. Daher sollte sie als zugeschriebener Bericht und nicht als vollständig verifizierter öffentlicher Befund behandelt werden.
Dabei handelt es sich um zwei Codex-Sandbox-Escapes, die vom Accomplish-Forscher Oren Yomtov offengelegt wurden. Der Forscher gibt an, beide Probleme am 12. August an OpenAI gemeldet zu haben. Sie seien innerhalb von acht Tagen behoben worden.
Plugin4Shell ist eine von AIR Security am 17. September 2026 offengelegte Schwachstelle in der Plugin-Lieferkette. AIR zufolge waren Claude Code, Codex, GitHub Copilot und Gemini CLI betroffen, weil nicht garantiert wurde, dass ein installiertes Plugin dem Commit entsprach, auf den der Marketplace das Plugin festlegen wollte.
Ja. Die Zero Day Initiative meldete am ersten Tag einen erfolgreichen Codex-Exploit durch Compass Security und am dritten Tag einen weiteren erfolgreichen Codex-Exploit durch Ikotas Labs. Doyensec demonstrierte ebenfalls einen Exploit, der als Kollision eingestuft wurde, weil der Hersteller den zugrunde liegenden Fehler bereits kannte.
OpenAI veröffentlichte die Codex-Security-CLI und das TypeScript-SDK im Juli 2026 als Open-Source-Software. Für den Zugriff auf bestimmte Cybersicherheitsfunktionen und geschützte Befunde kann weiterhin ein entsprechender OpenAI-Zugriff oder Trusted Access for Cyber erforderlich sein.
Nein. Kein einzelner Modus sollte als absolute Garantie betrachtet werden. Mehrere Befunde aus dem Jahr 2026 waren gerade deshalb relevant, weil die angreifbare Komponente außerhalb der erwarteten Modellsandbox arbeitete oder die vorgesehene Sicherheitsgrenze überschritt.
Verwenden Sie aktuelle Versionen, isolieren Sie nicht vertrauenswürdigen Code, beschränken Sie den Netzwerkzugriff, halten Sie langfristig gültige Zugangsdaten außerhalb der Ausführungsumgebung, prüfen Sie Plugins, nutzen Sie unabhängige menschliche Genehmigungen für folgenschwere Aktionen und protokollieren Sie die tatsächlichen Tool- und Systemaktivitäten des Agenten.
OpenAI nutzt Codex Security und Patch the Planet, um die defensive Schwachstellenforschung zu beschleunigen. Gleichzeitig ist Codex selbst zu einem zunehmend wichtigen Sicherheitsziel geworden, weil der Agent eng mit Quellcode, Tools, Zugangsdaten, Plugins und Software-Release-Workflows verbunden ist.
Zu den öffentlich verifizierten Vorfällen aus dem Jahr 2026 gehören Codex-Exploits bei Pwn2Own, Fehler bei der Isolierung der Start-Synchronisierung kuratierter Plugins, die Sandbox-Escapes Overpatch und Heapjack sowie Plugin4Shell. Der 360 Tulongfeng zugeschriebene „neue Zero-Day“ vom September sollte vorsichtiger bewertet werden, bis ein ausführlicher öffentlicher Hinweis klärt, wie er sich von früheren Problemen bei der Plugin-Synchronisierung unterscheidet.
Die übergeordnete Lehre ist in all diesen Fällen dieselbe: Die Sicherheitsgrenze eines KI-Coding-Agenten umfasst weit mehr als das Modell. Updater, Plugin-Manager, Git-Integration, Tool-Laufzeit, Hilfsprozesse, Netzwerkzugriff, Umgang mit Zugangsdaten und Genehmigungssystem werden alle Teil der Trusted Computing Base.
KI-Coding-Tools sind inzwischen vorgelagerte Softwareinfrastruktur. Ihre eigenen Sicherheitskontrollen müssen mit derselben Sorgfalt behandelt werden wie die Anwendungen und Lieferketten, an deren Erstellung sie mitwirken.
Starte mit einem Satz und erhalte in wenigen Minuten eine vollständige Website.