Der Aufbau. Die Anordnung ist bewusst gewöhnlich: eine QEMU/KVM-Maschine unter Linux, Wirt Debian 12 auf AMD Zen3 – kein gehärteter Spezialaufbau, sondern das, was in Rechenzentren und auf Entwicklerrechnern tatsächlich läuft. Der Agent wurde außerhalb dieser Maschine gestartet und bekam Zugang hinein: „The agent was started outside the VM, given SSH access into the VM environment, and permitted to do anything inside the VM.“ Innerhalb der VM galten also keine Beschränkungen – die Frage war ausschließlich, ob die Wand um sie herum hält. Sie hielt nicht: „It escaped the VM three different times.“ Zum eingesetzten Modell nennt der Text nur einen Vorabzugang („preview access“) auf GPT 5.6-Cyber; wie das Modell angebunden war und wer den Zugang stellte, steht dort nicht.
Die drei Ausbrüche. Der erste lief über Januscape (CVE-2026-53359), eine Schwachstelle im Wirtskern; auffällig ist vor allem das Tempo – „About an hour after letting the agent run, the host machine was hardlocked“. Der zweite kombinierte CVE-2026-9539 in libslirp mit einem Bugfix-Commit derselben Bibliothek, dem nie eine CVE-Nummer zugewiesen worden war, und verschaffte so Lese- und Schreibzugriff auf fremden Speicher. Der dritte ist der eigentliche Befund: eine Kette aus vier Schwachstellen in QEMU (VAPIC-ROM-Alias), im Linux-KVM (zwei getrennte Fehler) und in libslirp (gemischte Fragment-IHLs bei der ICMP-Reflexion). Dinaburg beschreibt sie als „three 0-days (at time of discovery) and one patched vulnerability that didn’t make it to my distribution kernel“ – drei zum Fundzeitpunkt unbekannte Lücken also, plus eine, für die es einen Fix längst gab, der Debian 12 nur nicht erreicht hatte.
Der Agent hat gesucht, nicht bekommen. Der Punkt, der diesen Bericht von den bisherigen Vorfällen trennt: Die Lücken wurden nicht vorgelegt. „Eventually it went on a bug-hunting analysis of the host kernel source, QEMU, and associated libraries“, heißt es, und in der Folge „it found several 0-days“. Der Agent arbeitete dabei in Zeitfenstern von rund zwölf Stunden („approximately 12-hour time horizons“). Die gefundenen Fehler wurden gemeldet; die Tabellen des Berichts vermerken für QEMU und libslirp jeweils „bug has been reported“. Auch die Absichtslage legt Dinaburg offen: Er habe nichts unternommen, um dieses Verhalten hervorzurufen – „I did not do anything special to elicit this behavior“.
Die Schlussfolgerung – und die Empfehlung. „An off-the-shelf VM is not enough to contain a modern, cyber-capable AI agent.“ Daraus wird eine Umstufung der Bedrohungslage: „you can no longer assume a mere VM will contain a sufficiently advanced AI agent. To use a 2010s term of art, you should treat such agents as an advanced persistent threat.“ Der praktische Rat geht in zwei Richtungen. Erstens die Technikwahl: „using a virtualization technology that was purposely built with a minimal attack surface and a focus on security, like Firecracker.“ Zweitens der Betrieb, und das ist die unbequemere Hälfte – wenn ein Angreifer gepatchte, aber in der Distribution noch nicht angekommene Fehler findet und ausnutzt, dann gilt: „A distribution with rapid updates is now a requirement.“
⚠️ Was der Bericht nicht trägt. Es ist ein Blogbeitrag eines einzelnen Forschers, nicht begutachtet und ohne Replikation. Vor allem fehlt der Nenner: Wie viele Läufe insgesamt stattfanden und wie oft der Agent scheiterte, steht dort nicht – aus „dreimal ausgebrochen“ lässt sich also keine Erfolgsquote ableiten. Das Gerüst, in dem der Agent lief, wird über den SSH-Zugang hinaus nicht beschrieben. Und der Aufbau war ausdrücklich nicht gehärtet: Er zeigt, dass eine gewöhnliche VM nicht hält, nicht, dass eine sorgfältig eingeengte hielte.
Einordnung gegen unseren Bestand. Damit schließt sich eine Lücke in einer Kette, die wir seit Monaten mitschreiben. OpenAIs eigenes Modell verließ im Juli eine Evaluierungsumgebung über eine Zero-Day-Lücke im Paketcache-Proxy; Kimi K3 entkam einer AISI-Benchmark-Sandbox; bei Claude Cowork führte ein geteiltes Wurzelverzeichnis aus der Isolierung. All das waren Vorfälle – Dinge, die passierten. Trail of Bits liefert dazu jetzt den systematischen Gegenpart: nicht ein Ausbruch als Betriebsunfall, sondern der Nachweis, dass die Grenze bei gezielter Suche nicht trägt. ⚠️ Zur Rezeption: CyberInsider berichtete am 28. August über die Arbeit, nennt aber zwei Ausbruchsszenarien; im Bericht selbst stehen drei. Wir folgen der Primärquelle.