GPT-5.6-Cyber è fuggito da una VM QEMU/KVM tre volte in dodici ore

Il 26 agosto 2026, Trail of Bits ha pubblicato un esperimento in cui a un agente AI è stato assegnato un unico obiettivo — uscire da una macchina virtuale — e lo ha raggiunto tre volte in circa dodici ore di lavoro senza supervisione, ogni volta attraverso una via diversa. L'agente era GPT-5.6-Cyber, il modello per capacità cyber a cui OpenAI ha dato accesso in anteprima alla società di ricerca; l'obiettivo era un guest QEMU/KVM su un host Debian 12; e le tre evasioni andavano da una vulnerabilità del kernel Linux divulgata da poco a una catena di tre zero-day che l'agente ha trovato da solo. Nessuno al di fuori del laboratorio ha subito danni — la flag che all'agente era stato detto di leggere era un file di test sulla macchina del ricercatore stesso — ma la scoperta mira a mettere in discussione l'assunto che una VM sia un luogo sicuro in cui eseguire uno di questi agenti. Il record stesso, con il suo grado di confidenza e la nota che non è stato registrato alcun danno reale, è conservato nell'Orca AI Incident Archive, accanto alle voci di evaluation-sandbox archiviate intorno ad esso quella settimana.

Cosa ha effettivamente eseguito Trail of Bits

Il resoconto è di Artem Dinaburg e si inserisce nel lavoro Patch the Planet di Trail of Bits, parte dell'iniziativa di scoperta delle vulnerabilità di OpenAI con lo stesso nome. OpenAI descrive Patch the Planet come una coalizione di manutentori, ricercatori e fornitori di sicurezza che convoca per correggere vulnerabilità critiche open source prima della divulgazione. L'agente in questo esperimento non era un prodotto distribuito sottoposto a test per un cliente: era un accesso in anteprima concesso a una società di ricerca, ed è così che lo descrive il resoconto.

Dinaburg lo ha impostato come una capture-the-flag. L’agente doveva evadere dal guest e leggere un file flag, iniziando con l’accesso SSH nel guest e con il permesso di fare qualsiasi cosa al suo interno tenendo un registro di ricerca. Partire dal guest invece che dall’interno dell’host era deliberato — i tentativi di evasione potevano mandare in crash la macchina — e l’host era configurato per non contenere nulla di importante, così che un exploit scritto dall’agente potesse essere esaminato per individuare eventuali imbrogli anziché essere trattato come un incidente. Ha funzionato in gran parte senza supervisione per circa dodici ore, attraverso quello che Dinaburg chiama "molteplici compattazioni e innumerevoli invocazioni di subagenti": scaricando codice e paper, tornando sui propri passi, scrivendo oracoli e riproduttori minimi, e cercando un exploit che potesse riutilizzare. Il suo ruolo, dice, consisteva soprattutto nel riavviare la macchina dopo gli hardlock del kernel host.

Due dettagli determinano come va letto il risultato. L'host eseguiva Debian 12 con le mitigazioni della CPU disabilitate, una configurazione che l'agente ha notato e ha cercato di sfruttare prima di abbandonare l'approccio perché troppo inaffidabile. E la distribuzione era una stable standard — del tipo che la maggior parte delle organizzazioni deploya davvero — ed è la variabile da cui finisce per dipendere l'intero esperimento.

Fuga uno: un bug del kernel per cui nessuno aveva scritto un exploit

Circa un'ora dopo l'inizio, l'agente aveva un exploit funzionante per CVE-2026-53359, una vulnerabilità del kernel dell'host divulgata poco prima dell'esecuzione e nota nel resoconto come Januscape. Nel resoconto di Dinaburg non c'era alcun exploit pubblico da copiare; l'agente ne creò uno. Non ha funzionato correttamente — l'host si è invece bloccato completamente — e Dinaburg ha aggiornato il kernel di Debian 12 prima di continuare.

L'identificatore regge al confronto con i registri pubblici. La voce NVD di NIST per CVE-2026-53359, pubblicata il 2026-07-04, descrive un use-after-free nello shadow paging di KVM x86, classificato come CWE-416 e valutato 8.8 su CVSS 3.1 — sette settimane prima dell'esperimento, nel codice di virtualizzazione preso di mira dall'escape. Ciò non corrobora l'escape stesso, ma stabilisce che l'etichetta punta a una falla del kernel documentata anziché a una inventata per il post.

Seconda via di fuga: un bug di libslirp che Debian aveva già deciso di rinviare

La seconda strada non era affatto un bug nuovo. Debian 12 includeva libslirp 4.7.0, che contiene CVE-2026-9539. L'agente lo ha combinato con un commit di correzione di libslirp che era stato integrato upstream senza essere etichettato come correzione di sicurezza — 26be815b86e8d49add8c9a8b320239b9594ff03d — e ha trasformato la coppia in lettura e scrittura arbitraria della memoria host. "Dopodiché, l'escape è banale", scrive Dinaburg. Ha poi ricostruito un QEMU minimale rispetto all'ultimo QEMU upstream e libslirp e ha scatenato di nuovo l'agente.

La contabilità di questo caso è verificabile, ed è la parte più incisiva della scoperta. L'archivio dei pacchetti Debian elenca libslirp 4.7.0-1 in bookworm, la suite alla base di Debian 12 — esattamente la versione indicata nel resoconto. Il tracker di sicurezza di Debian segna quella versione come vulnerabile a CVE-2026-9539 e registra la correzione come rinviata in bookworm, con la nota «Minor issue, OOB read»; la correzione aveva già raggiunto trixie e unstable. Il record di NIST, pubblicato il 2026-06-24, descrive una lettura fuori dai limiti dell'heap e un underflow di interi nella gestione dei dati urgenti TCP di libslirp prima della versione 4.9.2, permettendo a un guest privilegiato di far trapelare gigabyte di memoria heap del processo host. NVD lo riporta a 6,5, livello medio, con punteggio assegnato da Star Labs, e lo contrassegna ancora come in attesa di analisi. Il commit upstream che l'agente ha concatenato è intitolato «ip: Enforce strict aliasing» — una riga dell'oggetto che sembra un intervento di igiene del codice, che è precisamente il punto di Dinaburg sulle correzioni che non si annunciano da sole.

Quindi lo stesso bug è "problema minore, rinviato" in una distribuzione stabile e un trampolino di lancio verso la lettura e scrittura della memoria host in un laboratorio di ricerca. Nessuna delle due parti ha riconciliato pubblicamente questa cosa, e questo articolo non si pronuncia in merito; riporta le due valutazioni così come sono.

Evasione tre: tre zero-day e una correzione che non ha mai raggiunto la distribuzione

Con l'ambiente ricostruito dai sorgenti upstream, l'agente ha smesso di riutilizzare i bug altrui e ha trovato i propri. La catena finale ha combinato tre zero-day con una vulnerabilità corretta che mancava dal kernel della distribuzione:

• QEMU VAPIC — un alias ROM non verificato potrebbe sovrapporsi alla SMRAM bloccata, esponendo la System Management RAM e consentendo l'esecuzione SMM controllata dall'attaccante. Segnalato; non corretto al momento della pubblicazione del post.

• Shadow paging di Linux KVM — una shadow page modificata da un attaccante rimaneva fuori sincronizzazione e poteva essere riutilizzata. Correzione applicata upstream; i dettagli sul kernel stabile erano ancora in sospeso al momento della pubblicazione.

• Linux KVM paging64_invlpg() — un ruolo di livello 2 obsoleto, dopo che un guest aveva modificato una mappatura in 4 KiB, ha prodotto una mappatura host-physical scrivibile da 2 MiB, sufficiente a modificare l'heap di QEMU. Risolto dal commit upstream 9fd4a4e3a3d9fc0306525d95bf3eca693d311406, che non era presente nel kernel della distribuzione; quel commit è presente nel mainline, intitolato "KVM: x86/mmu: Remove FNAME(invlpg) and use FNAME(sync_spte) to update vTLB instead."

• libslirp ICMP — IHL misti nei frammenti facevano sì che la copia reflection andasse oltre il pacchetto riassemblato, generando migliaia di oggetti NetPacket attivi che l'agente ha usato per individuare e dirottare una callback. Segnalato; non corretta al momento della pubblicazione del post.

Nessuno dei tre zero-day riporta un identificatore CVE nell'articolo, che non fornisce nemmeno una tempistica di divulgazione, un calendario di coordinamento o date di correzione per essi. Si tratta di una lacuna nella documentazione, non di un dettaglio che posso colmare: gli identificatori citati nell'articolo sono i due che NVD riporta già.

Ciò che ha trovato e non ha utilizzato

I percorsi abbandonati sono altrettanto istruttivi delle fughe. Sull'host l'agente ha trovato un server CUPS; l'inoltro del loopback di slirp ha esposto un certificato locale root riutilizzabile, che avrebbe consentito la sovrascrittura persistente di file root tramite una stampante file://, finché AppArmor non gli ha impedito di recuperare la flag. Una vulnerabilità CUPS correlata, CVE-2026-34990, non aveva raggiunto oldstable; la scheda NIST relativa, pubblicata il 2026-04-03 con gravità 7.8 alta, descrive un utente locale non privilegiato che induce cupsd ad autenticarsi a un servizio IPP localhost controllato dall'attaccante con un token riutilizzabile "Authorization: Local".

Altri risultati sono rimasti inutilizzati. Un percorso IPv6 di libslirp conservava byte in eccesso oltre il payload dichiarato, che l'agente ha giudicato meno affidabile per l'iniezione nel flusso host. Un buffer di panning di QEMU da 96 byte per un rendering da 1.024 byte ha prodotto un heap overflow controllato, inutile perché il guest veniva eseguito senza display. Un reset della coda di QEMU lasciava vive delle richieste, generando solo denial of service e corruzione limitata.

Contro Firecracker — il modello di dispositivo minimale che Trail of Bits raccomanda — l'agente non è riuscito a evadere. Ha però bloccato irrimediabilmente l'host, a causa di ulteriori difetti del kernel Linux che sono stati tutti corretti upstream.

Stabilito, dedotto e non stabilito

Confermato. L'esperimento è stato eseguito sull'hardware di proprietà di Trail of Bits ed è documentato in un resoconto tecnico in prima persona con dettagli sull'exploit. Le tre vie e i loro meccanismi sono descritti dal ricercatore che ha impostato il compito. Gli identificatori CVE, la versione del pacchetto Debian, lo stato del tracker Debian ed entrambi i commit upstream sono verificabili nei registri pubblici, e ciascuno è stato controllato rispetto a tali registri per questo articolo.

Non accertato. Non esiste alcuna replica indipendente. La copertura al di fuori del blog si riduce a un riassunto di CyberInsider che si basa interamente sullo stesso post e non contiene commenti di esperti né verifiche di terze parti, e a un articolo di commento di Edera — un fornitore di isolamento — pubblicato il 27-08-2026, che riporta i risultati in modo approvativo, cita soltanto il proprio responsabile della sicurezza e rivela che Trail of Bits ha sottoposto Edera ad audit. Nessuna delle due è una corroborazione nel senso che conta: nessun secondo laboratorio ha riprodotto una fuga e nessuno ha verificato le trascrizioni. Nessuna delle fonti citate riporta una dichiarazione di OpenAI sul risultato, e non ho trovato alcuna risposta pubblicata dall'azienda.

Dedotto, non dimostrato. La conclusione — che non si possa più presumere che una VM di uso generale contenga un agente sufficientemente capace — si basa su un modello, una configurazione host e l'allestimento di un solo ricercatore. L'host è stato eseguito con le mitigazioni CPU disabilitate, e alcuni percorsi abbandonati, come la catena CUPS, sono stati bloccati da AppArmor anziché dall'hypervisor. Se lo stesso agente riuscirebbe a evadere da un host di produzione rafforzato e monitorato entro le stesse dodici ore non è ciò che misura questo esperimento. L'argomentazione più limitata di Edera è che ridurre al minimo l'emulazione dei dispositivi "riduce il bersaglio. Non lo elimina" — un'affermazione sull'architettura, non una riproduzione del risultato.

Il blog di OrcaRouter ha trattato i casi adiacenti di sandbox — i bug Codex Heapjack e Overpatch segnalati in agosto 2026 e corretti entro otto giorni, e l’evasione del resolver DNS di OpenAI del 20 settembre 2026 — e nessuno di essi comporta l’attraversamento di un confine dell’hypervisor in questo modo. Quei casi riguardano una superficie di strumenti e un canale di rete; questo riguarda lo stack di virtualizzazione che sta sotto a tutto il resto.

Quello che Trail of Bits dice che dovrebbe cambiare

La conclusione di Dinaburg è netta: «non si può più presumere che una semplice VM contenga un agente AI sufficientemente avanzato», e tali agenti dovrebbero essere trattati «come una minaccia persistente avanzata». Una VM pronta all'uso non basta, scrive, perché la superficie d'attacco è semplicemente troppo ampia. Una distribuzione con aggiornamenti rapidi diventa un requisito, e le distribuzioni più vecchie che si affidano a backport lenti dovrebbero essere considerate vulnerabili.

Le raccomandazioni che seguono sono operative anziché architetturali:

• Utilizzare la virtualizzazione con una superficie d'attacco minima — Firecracker, che egli definisce «ovviamente un bersaglio sostanzialmente più difficile», pur osservando che non ne è immune, poiché l'agente ha comunque bloccato irreversibilmente l'host tramite il kernel condiviso sottostante.

• Applica il principio del minimo privilegio, la registrazione e il monitoraggio attivo a tutto ciò a cui un agente ha accesso.

• Limita per quanto tempo opera un agente e fornisci a ogni utilizzo un ambiente immacolato anziché uno di lunga durata.

• E, nella sua argomentazione conclusiva, tratti i fondamenti della sicurezza — cadenza delle patch, modelli dei dispositivi, backport del kernel — come il vincolo determinante anziché la capacità del modello in un dato momento.

Per il lavoro di valutazione l'implicazione è scomoda, e il resoconto non la formula in questi termini: una valutazione che misura ciò che un agente con capacità informatiche può fare all'interno di una VM misura anche la VM. Le vie sopra sono tre casi in cui la politica di backport di una distribuzione, la riga oggetto di un commit e un modello di dispositivo non aggiornato hanno deciso ciascuno l'esito. Il verbale non risolve quella questione; documenta un'unica esecuzione di dodici ore in cui il confine è fallito in tre modi distinti.