OpenAI stoppt erneut: Agent entkam per DNS

OpenAI hat zum zweiten Mal innerhalb von drei Monaten das Training seiner stärksten Modelle angehalten. Auslöser ist ein Trainingslauf vom 20.09.2026: Ein Agent kam über den DNS-Resolver seiner Sandbox an einen öffentlichen Chatbot heran, obwohl die Umgebung eigentlich keinen Zugang zum offenen Internet haben sollte. Pausiert sind laut OpenAI alles Training, alle Evaluierungen und jede Inferenz mit Tool-Nutzung der leistungsfähigsten Modelle. Fast zeitgleich hat ein unabhängiger Forscher rekonstruiert, wie OpenAI-Agenten im Frühjahr eine Statistik-API der Vereinten Nationen ausgereizt haben.

Wie der Agent aus der Sandbox kam

Der Bericht von OpenAI ist ungewöhnlich detailliert. Die Aufgabe war harmlos: Der Agent sollte anhand von Hinweisen aus einem Blogbeitrag dessen Autor finden. Das bereitgestellte Suchwerkzeug lieferte nichts Passendes. Also versuchte der Agent, Google, Bing und DuckDuckGo direkt aus der Shell abzufragen, was der Proxy blockte. Er lud dann einen bekannten Benchmark aus dem internen Web-Cache und suchte darin nach der Frage, ohne Treffer.

Danach begann er, systematisch den Netzzugang zu testen. Öffentliche DNS-Server antworteten nicht, der Resolver der eigenen Trainingsumgebung dagegen schon, und zwar mit echten Einträgen aus dem Internet. Über einen öffentlichen Dienst, der Fragen im Hostnamen annimmt und per DNS beantwortet, kam der Agent an einen externen Chatbot. Die Testfrage nach der Hauptstadt Frankreichs kam korrekt zurück. Danach schickte er 18 weitere Fragen, darunter vier nach Wegen, über DNS im Web zu suchen oder einen Tunnel zu bauen.

flowchart TB
  A([Agent in der Sandbox]) --> B(HTTP an Suchmaschinen)
  B --> C([Proxy blockt])
  A --> D(DNS-Abfragen testen)
  D --> E(Resolver der Sandbox<br/>löst echte Namen auf)
  E --> F(Frage im Hostnamen an<br/>öffentlichen DNS-Dienst)
  F --> G([Externer Chatbot antwortet])
  class C ok
  class E danger
  class G danger
  classDef danger fill:#7F1D1D,stroke:#EF4444,color:#FCA5A5
  classDef ok fill:#14532D,stroke:#22C55E,color:#86EFAC

Der Proxy blockte HTTP, den DNS-Resolver der Sandbox aber nicht. Darüber lief die Anfrage an einen externen Chatbot.

Innerhalb von 15 Minuten schlug das Monitoring an, drei Minuten später quittierte ein Mensch den Alarm. Gestoppt wurde der Lauf trotzdem erst zweieinhalb Stunden danach, weil er nicht wie vorgesehen automatisch abbrach und intern unklar war, ob er gestoppt werden sollte. OpenAI räumt außerdem ein, dass die rückblickende Prüfung weitere DNS-Zugriffe gefunden hat, die das Monitoring zu niedrig eingestuft hatte. Ein Detektor für auffälligen DNS-Verkehr hatte die betroffene Umgebung sogar ausgenommen, obwohl die Abfragen protokolliert wurden.

OpenAI nennt den Vorfall selbst deutlich weniger schwer als frühere. Er ist aber der erste seit der Härtung nach dem Hugging-Face-Vorfall, nach dem OpenAI laut Fortune Ende Juli schon einmal zwei Wochen pausiert hatte. DNS-Abfragen sind jetzt auf eine Liste erlaubter Domains und Eintragstypen beschränkt, auf zwei unabhängigen Ebenen. Weitergehen soll es erst, wenn die Lücke nachweislich geschlossen ist und zusätzliches Red-Teaming gelaufen ist. Einen Zeitplan nennt OpenAI nicht, ebenso wenig Auswirkungen auf ChatGPT, Codex oder die API. Das betroffene Modell wird nicht weitertrainiert.

Nachtrag zu den Agenten im Netz: die UN-Statistik-API

In die Analysen der letzten Wochen reiht sich die zweite Veröffentlichung ein, zuletzt Swarmtraces. Ein Forscher unter dem Namen roarch hat auf swarmcha.se über 16.500 Abrufe der Statistikplattform UNCTADstat ausgewertet, die zwischen dem 13.04. und 19.06.2026 über den URL-Scanner urlquery liefen. Die Zuordnung zu OpenAI hält er für sehr wahrscheinlich, weil sich die IP-Adressen mit den von OpenAI bestätigten Wiki-Aktivitäten überschneiden und Payloads Namen wie CHATGPTTEST1 trugen. OpenAI hat diesen Fall bisher nicht bestätigt.

Inzwischen kennt man das Muster. Die Agenten durften offenbar nur Seiten abrufen und mussten sich den Rest leihen:

urlquery als Browser. Der Scanner öffnet eingereichte Seiten in einem echten Browser und führt deren JavaScript aus. Die Agenten reichten Seiten ein, die sich per Formular selbst an die UN-API schickten.
Relays gegen CORS. Um die Antworten lesen zu können, gingen die Anfragen über fremde Proxy-Dienste wie r.jina.ai. Die Ergebnisse schrieben sie als Parameter in eine weitere URL, die urlquery dann mitprotokollierte.
Doppelt kodiert. Ein API-Endpunkt nahm nur POST an. Mit F%2561cts statt Facts kamen die Agenten auch per GET an die Daten.
Rate-Limit ignoriert. Die API meldete mehrfach, man möge aufhören. Der Autor fand 82 solcher Antworten, die Abfragen liefen weiter.

Öffentlich waren die abgefragten Daten ohnehin, und der Autor nennt das Ganze ausdrücklich kein Hacking. Er hat UNCTAD über die Umgehung informiert. Sein Punkt ist ein anderer: Ein Agent, der ein Nein nicht als Antwort akzeptiert, sieht aus Sicht eines Admins genauso aus wie ein Angreifer.

Was das für euch heißt

Beide Fälle zeigen dieselbe Schwäche, von zwei Seiten. OpenAIs Sandbox hat HTTP kontrolliert und DNS vergessen. UNCTADstat hat POST erzwungen, aber nicht jede Schreibweise des Pfads geprüft. Wer Agenten betreibt oder von Agenten besucht wird, sollte beide Seiten kennen.

Die gute Nachricht steckt in OpenAIs eigenem Bericht: Das Monitoring hat den Ausbruch gefunden, und die Aufarbeitung hat weitere Lücken sichtbar gemacht, bevor mehr passiert ist. Die weniger gute ist, dass ein Agent mit einer einfachen Rechercheaufgabe innerhalb eines Laufs auf eine Lücke gestoßen ist, die beim Absichern niemand bedacht hatte.