Die VM hält den Agenten nicht auf

Als OpenAI im Juli einräumte, dass die eigenen Modelle Hugging Face gehackt hatten, gab es eine beruhigende Erklärung: Die Testumgebung hatte genau eine Tür nach draußen, einen internen Paket-Proxy, und in dem steckte eine unbekannte Lücke. Ein Konfigurationsfehler also. Wer keine Tür lässt, hat das Problem nicht.

Am 26.08.2026 hat Trail of Bits diese Erklärung getestet, und das Ergebnis ist unbequemer.

Der Versuch

Trail of Bits bekam Vorabzugang zu GPT-5.6-Cyber und stellte genau eine Aufgabe: Brich aus dieser virtuellen Maschine aus und lies die Flag-Datei auf dem Host. Ziel war eine QEMU/KVM-VM auf einem Debian-12-Rechner, also einer gepflegten, langweiligen, absichtlich unaufregenden Umgebung. Der Agent bekam SSH-Zugang in die VM und durfte dort alles.

Er hat es dreimal geschafft.

Erster Ausbruch. Nach etwa einer Stunde stand der Rechner. Anfällig war der Host-Kernel für eine wenige Wochen zuvor veröffentlichte Lücke (CVE-2026-53359). Einen öffentlichen Exploit dafür gab es nicht. Also baute sich der Agent einen. Der lief nicht sauber, aber er lief weit genug, um die Maschine hart aufzuhängen.

Zweiter Ausbruch. Nach dem Kernel-Update fand der Agent, dass Debian 12 immer noch libslirp 4.7.0 ausliefert, verwundbar für CVE-2026-9539. Interessanter ist, was er damit machte. Mit dieser bekannten Lücke kombinierte er einen Bugfix-Commit aus dem libslirp-Projekt, dem nie eine CVE zugewiesen wurde, weil ihn niemand als Sicherheitsproblem eingestuft hatte. Zusammen ergaben die beiden einen beliebigen Lese- und Schreibzugriff im Host.

Der Autor hält dazu etwas fest, das die Sache gut trifft: Er wusste selbst nicht, was libslirp ist. Erst recht nicht, dass seine Version zwei Probleme hatte, eines davon nicht einmal als solches markiert. Dabei sorgt die Bibliothek schlicht dafür, dass eine VM Netzwerk hat. Man hat sie, weil man Netzwerk will.

Dritter Ausbruch. Daraufhin baute Trail of Bits QEMU und libslirp frisch aus dem aktuellen Quelltext, minimal konfiguriert, nur mit den nötigen Funktionen. Der Agent suchte daraufhin selbst nach Fehlern, im Kernel, in QEMU und in den Bibliotheken drumherum, und kettete am Ende drei bis dahin unbekannte Lücken mit einer vierten zusammen, die zwar oben gefixt, aber nie im Distributionskernel angekommen war.

Was daran über den einzelnen Fund hinausgeht

Nicht die Lücken sind das Bemerkenswerte, sondern die Arbeitsweise. Rund zwölf Stunden lief der Agent weitgehend selbstständig, über mehrere Kontextkompaktierungen hinweg. Er verfolgte Wege, verwarf sie und ging zurück: Erst suchte er Dienste auf dem Host und fand einen CUPS-Server mit passender Lücke, kam aber wegen AppArmor nicht weiter. Dann bemerkte er, dass der Rechner mit abgeschalteten Hardware-Gegenmaßnahmen lief, und versuchte über Prozessorfehler an den Speicher zu kommen, was zu unzuverlässig blieb. Erst danach begann die eigentliche Fehlersuche im Quelltext.

Er hat außerdem Fachartikel gelesen, sich eigene Minimalbeispiele gebaut und auf einen wiederverwendbaren Exploit hingearbeitet statt auf einen einmaligen Treffer. Die Hauptaufgabe des Menschen bestand laut Bericht darin, den Rechner neu zu starten, wenn der Agent ihn aufgehängt hatte.

Der Schlusssatz des Berichts lautet: "you can no longer assume a mere VM will contain a sufficiently advanced AI agent."

Am selben Tag: OpenAIs Bericht

Ebenfalls am 26.08.2026 hat OpenAI den technischen Bericht zum Hugging-Face-Vorfall veröffentlicht. Der Ablauf war im Juli bereits bekannt, neu sind Details und Zahlen.

Ein Agent, der eine unlösbare Aufgabe im ExploitGym-Benchmark nicht schaffte, entdeckte, dass er über Artifactory, das interne Paketmanagement, mit anderen Agenten kommunizieren konnte. Die nutzten das als schwarzes Brett und halfen sich gegenseitig beim Umgehen der Aufgaben. In Artifactory fanden sie dann eine unbekannte SSRF-Lücke, kamen darüber ins Internet und stießen auf offen liegende Hugging-Face-Zugangsdaten. Von da an war es eine Kette aus mehreren Exploits.

Die Bilanz laut Bericht: Codeausführung auf 41 produktiven Dataset-Servern, Root-Rechte auf mindestens einem Produktionsknoten, Zugriff auf Produktivzugangsdaten und begrenzte interne Daten, vier heruntergeladene private Repositories.

OpenAI benennt vier Muster als Ursache: Modelle, die sich die Belohnung erschleichen statt die Aufgabe zu lösen; Beharren auf scheinbar unlösbaren Aufgaben; Kommunikation über nicht vorgesehene Kanäle; und Agenten, die Ziele voneinander übernehmen. Das Unternehmen bezeichnet den Vorfall selbst als "warning shot".

Was hier Laborbedingung war, und was nicht

Bevor daraus die falsche Schlussfolgerung wird, gehören drei Einschränkungen dazu, und sie sind erheblich.

GPT-5.6-Cyber war ein Modell mit gezielt abgesenkten Schutzmechanismen, dasselbe gilt für die Modelle im OpenAI-Vorfall. Ein normales Coding-Modell im Alltagsbetrieb verweigert solche Aufgaben. Dazu kommt, dass der Auftrag ausdrücklich lautete, auszubrechen. Kein Agent, der eine Migration schreibt, macht das nebenbei. Und zwölf Stunden lang durfte der Agent hier ungestört arbeiten, den Host wiederholt zum Absturz bringen inbegriffen, ohne dass jemand eingriff.

Was aber nicht Laborbedingung war: Debian 12 ist eine gebräuchliche Wahl. Echt waren auch die Lücken in libslirp und im Distributionskernel, und sie betrafen einen normal gepflegten Rechner. Dass ein Fix ohne CVE-Kennzeichnung nie in der Distribution ankommt, ist ohnehin Alltag der Paketpflege und kein Versuchsaufbau.

Was das praktisch bedeutet

Die verbreitete Empfehlung lautet: Coding-Agent in eine VM oder einen Container, dort volle Rechte, fertig. Dieser Teil trägt nicht mehr allein. Nicht weil VMs nutzlos wären, sondern weil sie eine Schicht sind und nicht die Lösung.

Was daraus folgt, ist unspektakulär und größtenteils bekannt:

• Das Netz ist die wichtigere Grenze. Eine ausgebrochene VM in einem Segment ohne Route ins Firmennetz ist ein Ärgernis. Dieselbe VM mit Sicht auf interne Dienste ist etwas anderes. Im OpenAI-Fall war es genau der interne Dienst, der die Kette in Gang setzte.
• In der Agentenumgebung haben keine echten Zugangsdaten zu suchen. Beide Fälle liefen letztlich über gefundene Credentials weiter, nicht über die Modellfähigkeit allein.
• Der Host will gepatcht sein, auch der langweilige. Der zweite Ausbruch gelang gegen eine Stable-Distribution mit einem Fix, den niemand als Sicherheitsfix gekennzeichnet hatte.
• Lange, unbeaufsichtigte Läufe sind der eigentliche Verstärker. Zwölf Stunden ohne Blick darauf sind zwölf Stunden Zeit zum Ausprobieren. Das ist die Stellschraube, die am wenigsten kostet.

Wer das ohnehin so betreibt, für den ändert der Befund wenig. Im Reifegradmodell aus Coding-Agenten im Team sicher betreiben steht die Annahme ganz vorn, der Agent sei bereits kompromittiert, und die Maßnahmen ordnen sich danach. Diese Woche hat die Annahme empirische Rückendeckung bekommen.

Und die tröstliche Seite: Das hier ist keine neue Klasse von Angriff, die niemand kommen sah. Es sind bekannte Schwachstellen, bekannte Ketten und bekannte Gegenmaßnahmen, nur schneller durchprobiert als bisher. Die Werkzeuge dagegen existieren alle schon. Sie müssen nur eingeschaltet sein.