PwnEscape: il bug non era in KVM, ma il confine è saltato

Quando diciamo che una macchina virtuale è isolata, stiamo spesso descrivendo un’aspettativa più che una proprietà verificata. Il guest non dovrebbe poter leggere la memoria dell’host, il suo processo non dovrebbe decidere cosa succede agli altri tenant e l’hypervisor dovrebbe mantenere il confine. Tutto ragionevole. Poi arriva una vulnerabilità che non nasce nel cuore di KVM, ma nel networking IPv4 del kernel Linux, e ricorda una cosa poco comoda: il confine di sicurezza attraversa anche componenti che nessuno aveva messo al centro del diagramma.

Il caso si chiama PwnEscape, identificato come CVE-2026-99999 e divulgato pubblicamente il 15 ottobre 2026. Il ricercatore Paulos Yibelo e il team pwn.ai descrivono una falla legata ai metadati usati per calcolare in differita i checksum dei pacchetti. Una parte della prova è stata confermata nell’ambiente Sandbox di Vercel; altri risultati più gravi riguardano macchine controllate dai ricercatori. La distinzione non è una nota a piè di pagina: è il punto da cui partire per capire la gravità senza trasformare ogni dimostrazione in una compromissione universale.

L’isolamento non coincide con il codice dell’hypervisor

KVM è un pezzo fondamentale dell’architettura, non l’intera architettura. Una VM comunica con il mondo attraverso interfacce virtuali, percorsi di rete, filtri, driver e servizi che appartengono all’host. Alcuni ricevono informazioni generate in un ambiente meno fidato e le trasformano in operazioni privilegiate. Se un solo passaggio tratta quelle informazioni come affidabili quando non lo sono, l’isolamento può fallire senza che ci sia un bug nel componente che tutti stavano osservando.

È una dinamica già nota in altri contesti: la vulnerabilità non sempre abita nel modulo con l’etichetta “sicurezza”. A volte è nell’integrazione tra due componenti corretti presi singolarmente, oppure in un’ipotesi che non rimane vera dopo una trasformazione. Ne avevo affrontato un aspetto vicino parlando dei confini di fiducia nelle applicazioni Django: il problema interessante non è il numero dei bug, ma il punto in cui una rappresentazione viene promossa a verità.

Un checksum differito non è soltanto un’ottimizzazione

Per ridurre lavoro inutile, lo stack di rete può rimandare il completamento del checksum di un pacchetto. Invece di scrivere subito il risultato, conserva dei metadati che indicano dove l’operazione dovrà avvenire. Nel kernel Linux questa modalità è nota come CHECKSUM_PARTIAL. È una tecnica ordinaria e utile, non una scorciatoia intrinsecamente insicura.

Il dettaglio decisivo è che quei metadati non descrivono soltanto un pacchetto: influenzano una scrittura futura sui suoi byte. Se arrivano da un’origine meno fidata, non basta controllare che sembrino plausibili all’ingresso. Bisogna garantire che il loro significato resti valido anche dopo i passaggi successivi: rimozione delle intestazioni di collegamento, interpretazione IPv4, routing e frammentazione. In PwnEscape il problema è proprio questa continuità dell’invariante.

Secondo l’analisi tecnica originale di pwn.ai, il completamento tardivo del checksum poteva modificare byte di un header IPv4 già interpretato dal kernel. Una fase successiva usava allora la nuova rappresentazione come se fosse stata validata in precedenza. Il risultato dimostrato include una divulgazione di memoria dell’host. Non serve raccontare la sequenza operativa dell’exploit per capire il difetto di progettazione: un controllo può essere corretto nel momento in cui viene eseguito e diventare insufficiente se una trasformazione successiva cambia l’oggetto controllato.

Un dato non diventa affidabile perché lo abbiamo validato una volta. Rimane affidabile soltanto se tutte le trasformazioni successive conservano le condizioni su cui quella validazione si basava.

Questa è la parte che trovo più interessante dal punto di vista ingegneristico. Ci piace parlare di componenti, responsabilità e layer, ma gli invarianti attraversano i layer. Se una decisione dipende da un valore e un’operazione differita può ancora modificarlo, la validazione va ripensata rispetto all’intero percorso. È una lezione applicabile ben oltre il networking, senza dedurne automaticamente che altri protocolli o prodotti siano vulnerabili.

Tre risultati diversi che non vanno messi nello stesso sacco

La sigla CVE e un punteggio di gravità elevato non sostituiscono la lettura delle prove. Qui esistono almeno tre livelli da distinguere. Primo: il ricercatore ha mostrato una divulgazione ripetibile di memoria dell’host. Vercel ha confermato la fase di memory disclosure sulle proprie sandbox in produzione. Secondo: i ricercatori riferiscono crash dell’host in ambienti di laboratorio controllati. Terzo: descrivono una catena di esecuzione con privilegi host-root ottenuta sulle loro macchine, non su un’infrastruttura di produzione del provider.

Sono risultati importanti, ma non intercambiabili. Una lettura di memoria non dimostra da sola l’esecuzione arbitraria; un’esecuzione riuscita in un laboratorio non dimostra che ogni installazione KVM sia sfruttabile nello stesso modo. Vercel precisa inoltre che, nell’ambito della challenge, non sono state presentate prove di lettura di file, segreti o dati applicativi dei clienti. Questo non rende irrilevante il bug: rende più rigorosa la descrizione di ciò che sappiamo.

Anche la classificazione come vulnerabilità critica va interpretata correttamente. Non si tratta di un invito a credere che qualunque pacchetto proveniente da Internet consenta di prendere il controllo di un server Linux. Lo scenario documentato richiede un contesto in cui un attaccante controlli un workload guest e possa raggiungere i percorsi di networking pertinenti. La valutazione del rischio dipende quindi dall’architettura reale, dal kernel host e da come vengono gestite le interfacce virtuali.

La patch risolve un’invariante precisa, non tutti i problemi futuri

La correzione upstream è il commit Linux 6785011f8b16, firmato da Michael S. Tsirkin. Introduce una verifica prima del completamento del checksum nei percorsi IPv4 interessati, impedendo che il punto previsto per l’operazione cada all’interno dell’header di rete già interpretato. La modifica riguarda più punti di consumo del checksum, non soltanto la frammentazione.

Il messaggio del commit è particolarmente istruttivo: gli autori la descrivono come una misura di defense in depth e chiariscono che una validazione più completa all’ingresso richiede altro lavoro. Questo è il linguaggio che vorrei leggere più spesso nei changelog di sicurezza. Non promette che un intero sottosistema sia diventato infallibile; definisce la proprietà che il fix intende garantire e lascia espliciti i limiti del suo perimetro.

L’esistenza di un commit mainline non significa automaticamente che ogni host sia aggiornato. Le distribuzioni applicano backport, mantengono rami differenti e pubblicano advisory con tempi propri. Per capire se un sistema è protetto serve verificare il pacchetto kernel effettivamente distribuito e soprattutto quello attualmente in esecuzione. Limitarsi a confrontare una stringa di versione con quella del repository principale può essere fuorviante.

Che cosa dovrebbe verificare chi gestisce infrastrutture

Per un responsabile tecnico la domanda utile non è “uso KVM, quindi sono vulnerabile?” ma “quale kernel host eseguo, quali percorsi di networking espongo ai guest e quale correzione è disponibile per la mia distribuzione?”. L’advisory AWS distingue, per esempio, i servizi gestiti dichiarati non interessati da configurazioni di virtualizzazione autogestite che possono richiedere intervento. Non è una garanzia trasferibile automaticamente ad altri provider o ambienti.

• Consultare gli advisory del proprio vendor e verificare se la correzione specifica è inclusa nel kernel host installato, tenendo conto dei backport.
• Verificare che il kernel corretto sia effettivamente in esecuzione: installare un pacchetto senza attivarlo non conclude la remediation.
• Mappare i percorsi di rete e i confini tra workload non fidati e host, senza supporre che l’isolamento sia garantito dalla sola presenza dell’hypervisor.
• Registrare le verifiche effettuate e rivalutare il rischio quando cambiano kernel, componenti virtuali o configurazioni di rete.

Non è una checklist miracolosa. È manutenzione ordinaria fatta con un modello corretto del sistema. Una mitigazione operativa può ridurre la superficie o l’impatto, ma non va presentata come equivalente alla correzione del difetto. E aggiornare il kernel del guest non sostituisce l’aggiornamento del kernel host quando il problema si trova in quest’ultimo.

Le sandbox per agenti AI rendono il confine ancora più importante

Il caso emerge da una challenge dedicata alle sandbox che eseguono codice non fidato. Il collegamento con gli agenti AI non è un espediente per aggiungere due parole di moda: sempre più sistemi automatizzati eseguono strumenti, dipendenze e codice generato in ambienti isolati. Questo aumenta il valore operativo di una separazione robusta tra workload e infrastruttura. Non cambia però la fisica del problema. Una VM rimane una VM, e il suo isolamento continua a dipendere da tutti i componenti host raggiungibili.

Ho già scritto che la sicurezza degli agenti non può stare nel prompt. Qui la stessa idea scende di un livello: neppure un’etichetta “sandbox” può sostituire i controlli applicati davvero dal sistema operativo, dalla rete e dai processi privilegiati. Le promesse commerciali non sono invarianti verificati.

La domanda da fare al prossimo diagramma architetturale

PwnEscape non dimostra che virtualizzare sia inutile, che Linux sia intrinsecamente insicuro o che tutti i cloud siano compromessi. Dimostra qualcosa di più concreto: una decisione di sicurezza può dipendere da informazioni che attraversano più sottosistemi, e una trasformazione legittima può invalidare le ipotesi di chi ha controllato quelle informazioni prima. Il lavoro dei maintainer e la correzione upstream sono la risposta tecnica a un difetto specifico, non una promessa metafisica di sicurezza assoluta.

La prossima volta che un diagramma disegna una linea netta tra guest e host, la domanda interessante non è soltanto chi possiede quella linea. È quali dati la attraversano, quali componenti li reinterpretano e chi garantisce che una verifica resti vera dopo l’ultima trasformazione. Perché i confini disegnati bene sono utili. Quelli verificati lungo tutto il percorso sono molto più utili.