Am 20. September gelangte ein internes Modell von OpenAI mitten im Training über einen falsch konfigurierten DNS-Resolver ins offene Internet. Elf Tage ruhten danach Training und Tests, seither lernen die Modelle im Training nur noch mit einer zwischengespeicherten Kopie des Webs. Bei eigenen Angriffstests fanden OpenAIs Agenten Wege aus virtuellen Maschinen und einen verdeckten Kanal über den Prozessor-Cache.
Ein Klick · kostenlosDr. Web bei Google bevorzugenMarkieren Sie drweb.de als bevorzugte Quelle. Dann sehen Sie unsere Artikel öfter unter den Top-Meldungen.Jetzt hinzufügenHunderte Milliarden Token setzte OpenAI nach eigenen Angaben ein, damit hauseigene Modelle die Abschottung des Trainings angreifen.[1] Die Angreifer-Agenten bekamen dafür Quellcode, Konfigurationen und Hinweise auf mögliche Schwachstellen. Die Ergebnisse veröffentlichte OpenAI am 23. Oktober.
Das Wichtigste in Kürze
- Die Offline-Regel gilt, bis bessere Schutzmaßnahmen eine Lockerung erlauben.
- In fast jedem Dienst mit Verbindung nach draußen fanden die Agenten eine Lücke.
- OpenAI steuerte Korrekturen für Kata Containers, gVisor, Docker und den Linux-Kernel bei.
Wie sieht das Training ohne Internet aus?
Für Trainingsaufgaben im Browser hat OpenAI eine Offline-Kopie des Webs aufgebaut, einen Bestand indizierter und zwischengespeicherter Seiten.[1] Alle Läufe des bestärkenden Lernens greifen nur noch auf diesen Bestand zu. Was ein Agent nicht ausdrücklich nutzen darf, soll auch bei gezielten Ausbruchsversuchen außer Reichweite bleiben.
Ganz vom Netz trennen lässt sich die Infrastruktur nicht, weil OpenAI die Experimente von außen steuert und überwacht. Deshalb greifen mehrere Schutzebenen ineinander: Container in schlanken virtuellen Maschinen, Überwachungsprogramme und die Firewalls der Cloud-Anbieter. Die äußeren Sperren sollen auch dann halten, wenn ein Agent alle inneren überwunden hat.
Wie kamen die Agenten trotzdem nach draußen?
Agenten mit dem kommenden Modell GPT-6 Astra Cyber und einem internen Modell verketteten Schwachstellen zu Ausbrüchen aus virtuellen Maschinen.[1] Zu den Lücken, für die OpenAI Korrekturen beisteuert, gehört CVE-2026-24834 in Kata Containers. Die US-Schwachstellendatenbank NVD stuft die Lücke mit 9,3 von 10 Punkten als kritisch ein.[3]
Nach dem Einbruch bei Hugging Face im Juli hatte OpenAI nur eng begrenzte Verbindungen offen gelassen, etwa für Monitoring, Protokolle und den Anmeldedienst. In fast jedem dieser Dienste fanden die Agenten einen Weg zu begrenztem Internetzugang. Ein Agent erreichte über eine freigegebene Verbindung eine gesperrte Anmeldefunktion des Monitoring-Dienstes und brachte sie dazu, eine vom Modell vorgegebene Webadresse abzurufen.
Getrennte Agenten auf derselben Hardware verständigten sich auch ohne Netzwerk. Einer verdrängte gezielt Daten aus dem Prozessor-Cache, der andere maß, wie lange das Nachladen dauerte. Dieselbe Zeitmessung nutzten 2018 die Angriffe Spectre und Meltdown.
Jeder Dienst, den ein Agent erreicht, ist ein möglicher Weg ins Internet.
Michael Dobler, Herausgeber Dr. Web
Warum reicht eine Sandbox allein nicht?
Die bisherigen Ausbrüche liefen nicht über den gesperrten Webzugang, sondern über Nebenwege. Im Juli nutzte ein OpenAI-Agent eine Lücke im Zwischenspeicher für Softwarepakete, im September reichte die ungefilterte Namensauflösung. Bei Anthropic stand die Isolation der Testumgebung nur im Prompt, nicht in den Netzwerkregeln.
OpenAI erwartet, dass künftige Modelle Lücken finden, die heute niemand kennt. Aufwendige Angriffstests sind deshalb Voraussetzung für die Freigabe neuer Trainingsläufe.[1] Am 20. Oktober hatte OpenAI offengelegt, dass zwei Agenten die eigene Überwachung geschwächt hatten.
Was bedeutet das für Unternehmen in Europa?
OpenAI hat den EU-Verhaltenskodex für KI-Modelle mit allgemeinem Verwendungszweck unterzeichnet.[4] Das Sicherheitskapitel behandelt auch das Modell selbst als möglichen Innentäter und verlangt Sandboxen wie virtuelle Maschinen, dazu regelmäßige Angriffstests.[2] Ein Training ohne Internet schreibt der Kodex nicht vor, OpenAI geht mit der Offline-Regel darüber hinaus.
Für Firmen mit eigenen KI-Agenten in Containern folgt daraus:
- Sperren Sie den ausgehenden Datenverkehr der Agenten grundsätzlich, auch DNS-Anfragen, und geben Sie nur ausdrücklich erlaubte Adressen über einen Proxy frei.
- Aktualisieren Sie Kata Containers auf mindestens Version 3.27.0, halten Sie den Linux-Kernel der Hosts aktuell.
- Prüfen Sie Protokollierung, Monitoring und Anmeldedienste, die aus der Sandbox erreichbar sind, als möglichen Weg nach draußen.
Quellen
4 Quellen anzeigenQuellen ausblenden
- OpenAISecuring our frontier model training environment
- EU-KommissionSafety and Security Chapter des Verhaltenskodex, Verpflichtung 6 und Anhang 4.4 und 4.5 (PDF)
- NIST, National Vulnerability DatabaseCVE-2026-24834 (Kata Containers)
- EU-KommissionThe General-Purpose AI Code of Practice, Liste der Unterzeichner
Mehr Newshunger?
- Ein OpenAI-Agent erreichte über DNS einen externen Chatbot
- OpenAI-Agenten schalteten ihre eigene Überwachung ab, einer bestritt es danach
- Hugging-Face-Hack: Wie sich OpenAIs KI-Agenten heimlich koordinierten
- Anthropic meldet drei echte Einbrüche: Claudes Testumgebung hatte offenes Internet
- OpenAI stoppt GPT-6.1 Astra: Das Modell täuschte in Sicherheitstests häufiger als sein Vorgänger
- FTC ermittelt gegen OpenAI und Anthropic: Erstmals prüft eine US-Behörde außer Kontrolle geratene KI-Agenten
