Pagate pochi euro al mese per una VPS, ci installate quello che volete e date per scontato che il vostro vicino di server, quello che gira sulla stessa macchina fisica, non possa vedere nulla di ciò che fate. È la promessa su cui si regge buona parte del cloud. PwnEscape la mette in discussione: da dentro una macchina virtuale, con pacchetti di rete costruiti ad arte, si arriva a leggere la memoria del kernel dell’host, a mandarlo in crash e, in laboratorio, a eseguire comandi come root sull’host stesso.
La vulnerabilità è tracciata come CVE-2026-99999; il team CVE del kernel Linux le ha assegnato un punteggio CVSS di 9.3, critico, ed è stata resa pubblica il 15 ottobre 2026. Il codice vulnerabile risale al 2008, con Linux 2.6.27: quasi diciotto anni di kernel, cioè praticamente qualsiasi distribuzione abbiate mai installato.
La storia, però, comincia con una scommessa da un milione di dollari.
Il 18 agosto Vercel ha lanciato una sfida pubblica su HackerOne: due settimane e un montepremi fino a un milione di dollari per chiunque riuscisse a evadere da Vercel Sandbox, il servizio che esegue codice non fidato, spesso generato da agenti AI, dentro microVM Firecracker su host EC2 bare metal.
Al terzo giorno è arrivato il report più importante del programma, firmato da Paulos Yibelo di PWNAI Research, partito da una sandbox standard e senza accessi particolari. Il team ha lavorato con Omega-Pwn, un harness di ricerca sperimentale costruito anche su OmegaClaw, con GPT-5.6 Sol come motore di ragionamento per l’analisi del sorgente e le persone a decidere perimetro e prove. Costo dichiarato in token API: sotto i 700 dollari. A sfida conclusa, Vercel ha contato 1.285 report e 242.000 dollari pagati, con un solo finding critico: questo.
Il 4 settembre i ricercatori hanno segnalato il problema in privato ai maintainer del kernel, già con delle patch candidate. Tre giorni dopo Michael S. Tsirkin di Red Hat lo ha riprodotto, e la sua correzione, ipv4: validate checksum_start before completing checksum, è entrata in net.git l’8 ottobre e nel ramo di Linus il 14.
Il nome trae un po’ in inganno: in KVM non c’è nessun bug.
Il difetto sta nello stack IPv4 dell’host e riguarda il checksum offload. Calcolare il checksum di ogni pacchetto costa CPU, quindi Linux permette di rimandarlo: il pacchetto viaggia marcato come CHECKSUM_PARTIAL, con due numeri che dicono da dove partire con il calcolo e in quale punto scrivere il risultato. Più avanti la scheda di rete o la funzione skb_checksum_help() farà il conto e scriverà lì. Quando una VM spedisce un pacchetto attraverso la sua scheda virtio-net, è il guest a fornire quei due numeri. E l’host li prendeva per buoni senza controllare che il punto di scrittura cadesse dopo l’header IPv4.
Il bersaglio è il primo byte dell’header, che contiene la lunghezza dell’header stesso (IHL). Il kernel lo legge come 0x45, cioè 20 byte, e su quella base prende le sue decisioni di instradamento. Poi la scrittura differita del checksum lo trasforma in 0x4f: 60 byte. La frammentazione IPv4 rilegge la lunghezza solo dopo aver completato il checksum e copia 60 byte credendoli tutti header, ma nel caso dei ricercatori i dati validi erano 28: i 32 byte in eccesso sono memoria del kernel dell’host, che esce nei frammenti sotto forma di opzioni IP e torna all’attaccante. Il percorso, semplificato e spiegato da pwn.ai, è questo:
Non c’è nessuna race condition da vincere (anche se potrebbe sembrare): è un time-of-check/time-of-use del tutto deterministico, in cui tra controllo e uso passa solo la normale sequenza di operazioni dello stack di rete.
Da 32 byte di memoria a root sull’host il passo è lungo.
Il leak è ripetibile finché il guest continua a mandare pacchetti ed è stato dimostrato contro le sandbox di produzione di Vercel. Su macchine KVM e Firecracker di loro proprietà, configurate come quelle di Vercel, i ricercatori hanno fatto crollare l’host con due soli pacchetti, e con lui tutte le VM ospitate. Sempre in laboratorio hanno usato le letture per orientarsi nella memoria dell’host, ottenuto scritture controllate da 64 byte nel kernel e le hanno concatenate fino a eseguire un programma come root sull’host, in quattro avvii a freddo distinti. I dettagli di quest’ultima parte arriveranno in un secondo articolo e al momento non c’è codice di exploit pubblico, ma gli stessi ricercatori si aspettano exploit per le configurazioni più deboli nel giro di settimane. Con il write-up tecnico già online, chi sa leggere un diff ha parecchio materiale da cui partire.
I titoli sulla fine dell’isolamento nel cloud vanno comunque ridimensionati. Secondo The Register Amazon ha dichiarato che EC2 non è a rischio, e il modo in cui Google usa KVM dovrebbe proteggere anche Google Cloud. Chi ha una VPS non deve aggiornare niente dentro la propria macchina, perché la correzione va applicata al kernel dell’host. Il rischio concreto ricade su chi gestisce in proprio host KVM con guest di altri: provider VPS, cloud privati, piattaforme di sandbox, cluster Proxmox condivisi.
Il problema va anche oltre le VM. Secondo la valutazione di Red Hat la falla può essere innescata anche da un attaccante locale senza nessuna VM di mezzo, e nella discussione upstream sono stati considerati scenari con TUN e AF_PACKET. Lo stesso Tsirkin, nella patch, la descrive come difesa in profondità: impedisce di sovrascrivere l’header IPv4, mentre una validazione completa dei pacchetti in ingresso è ancora da scrivere.
Quindi, chi deve aggiornare e cosa?
La correzione è nei kernel stable 7.2.11, 6.18.57, 6.12.113, 6.6.159, 6.1.190, 5.15.223 e 5.10.272, e il team CVE del kernel raccomanda di passare all’ultima stable invece di applicare il singolo commit. Debian ha già portato il 6.12.113 su Trixie con la DSA-6568-1; per le altre distribuzioni e per prodotti come Proxmox controllate l’advisory del vendor e cercate nel changelog il commit 6785011f8b16. Non esistono workaround: serve il kernel aggiornato e serve riavviare, e su un hypervisor conviene migrare o spegnere i guest prima del reboot.
Il confine di una VM è grande quanto tutto il sistema operativo che le sta sotto.
Siamo abituati a pensare all’isolamento delle macchine virtuali come a una questione di hypervisor, e quest’estate con Januscape il bersaglio era proprio la shadow MMU di KVM. PwnEscape ricorda che un guest parla con molto altro: emulazione dei dispositivi, rete virtuale, allocatori, ottimizzazioni nate per le prestazioni che nessuno aveva guardato come confine di sicurezza. I ricercatori parlano di una possibile nuova classe di attacchi, in cui metadati non fidati modificano campi che il kernel ha già validato, e se hanno ragione questo commit sarà solo il primo di una serie.
Come per Copy Fail e Dirty Frag, la ricerca assistita da modelli AI sta setacciando codice vecchio di quasi vent’anni a una velocità mai vista, con budget da qualche centinaio di dollari. Se gestite host di virtualizzazione con guest che non controllate, aggiornate il kernel, riavviate e verificate con uname -r che stia girando la versione giusta. La seconda parte dell’exploit arriverà, resta da capire se prima o dopo il vostro reboot.
Red Team & Offensive Security Engineer
Parlo di sicurezza informatica offensive, Linux e Open Source
