Il 6 agosto 2026 è stata resa pubblica Zapscape, una vulnerabilità che interessa il sistema di virtualizzazione nativo del Kernel Linux KVM x86/x86_64 e che può consentire a un attaccante presente all’interno di una macchina virtuale di eseguire codice sul sistema host. La vulnerabilità è identificata come CVE-2026-64561 e risiede nel codice della Shadow MMU del Kernel. Il problema è particolarmente interessante perché riguarda una funzionalità utilizzata in determinati ambienti di virtualizzazione: la nested virtualization.

Ma per capire Zapscape è utile fare un piccolo passo indietro.

In una configurazione tradizionale abbiamo un host fisico, indicato come L0, che esegue KVM e ospita una macchina virtuale, indicata come L1. Con la nested virtualization, la macchina virtuale L1 può a sua volta comportarsi come un hypervisor ed eseguire una seconda macchina virtuale, indicata come L2.

Possiamo quindi rappresentare l’architettura nel seguente modo:

I processori moderni offrono estensioni hardware come Intel VT-x e AMD-V per supportare la virtualizzazione. In un ambiente nested, il livello L0 deve gestire anche le operazioni di virtualizzazione richieste dal livello L1. Questo introduce ulteriori livelli di traduzione della memoria e, di conseguenza, maggiore complessità nel codice dell’hypervisor, ed è proprio in questa parte di KVM che entra in gioco Zapscape.

Zapscape interessa la Shadow Memory Management Unit, conosciuta semplicemente come Shadow MMU, presente nel codice KVM per x86. La Shadow MMU si occupa di gestire le traduzioni delle pagine di memoria utilizzate dalle macchine virtuali. In un ambiente nested il problema diventa ancora più complesso, perché KVM deve gestire le relazioni tra le tabelle delle pagine appartenenti ai diversi livelli di virtualizzazione. Durante il normale funzionamento, queste strutture vengono continuamente create, aggiornate e rimosse.

La vulnerabilità nasce durante le operazioni di reclaim della memoria. In determinate condizioni, KVM può liberare una struttura utilizzata dalla Shadow MMU e successivamente continuare a utilizzarne un riferimento. Si tratta ancora del classico use-after-free (UAF), ovvero di un tipo di vulnerabilità di corruzione della memoria molto diffuso, specialmente nelle ultime CVE rilasciate.

Nel caso di Zapscape, il comportamento avviene all’interno di una componente particolarmente privilegiata del sistema di virtualizzazione.

La parte più interessante della vulnerabilità riguarda il possibile guest-to-host escape.

Un attaccante che controlla una macchina virtuale può manipolare le operazioni effettuate dal guest e creare le condizioni necessarie per raggiungere il percorso vulnerabile della Shadow MMU. Sfruttando il comportamento di use-after-free, l’attaccante può arrivare a influenzare strutture di memoria utilizzate da KVM. Il risultato può essere l’esecuzione di codice sul sistema host con privilegi root.

In uno scenario cloud, questo rappresenta una situazione particolarmente delicata. Un attaccante potrebbe partire da una singola VM affittata presso un provider e arrivare al sistema che gestisce la macchina fisica sottostante.

Da quel punto l’impatto dipende dall’architettura dell’infrastruttura, dalle altre VM presenti sull’host e dalle ulteriori misure di isolamento adottate.

Tra gli scenari possibili rientrano:

• Remote Code Execution sul sistema host
• compromissione delle altre macchine virtuali presenti sullo stesso host
• accesso a dati e credenziali disponibili sul sistema host
• Denial of Service attraverso il crash del kernel

È quindi una vulnerabilità che colpisce direttamente uno dei principali presupposti della virtualizzazione: l’isolamento tra guest e host. Di seguito vediamo una Proof of Concept direttamente divulgata dalla repository GitHub del ricercatore che ha scovato la vulnerabilità:

Zapscape presenta però anche un secondo scenario interessante. Su alcune distribuzioni Linux, tra cui configurazioni di RHEL, il device /dev/kvm può essere accessibile in scrittura anche da utenti non privilegiati. Con permessi 0666, infatti, qualsiasi utente locale può interagire direttamente con l’interfaccia KVM.

In questo scenario la vulnerabilità può essere utilizzata come Local Privilege Escalation (LPE). L’attaccante parte quindi da un normale account locale e sfrutta KVM per arrivare all’esecuzione di codice con privilegi root. Questo scenario può risultare persino più semplice da sfruttare rispetto al guest-to-host escape, visto che l’attaccante può interagire direttamente con le interfacce KVM disponibili sul sistema.

La presenza del codice vulnerabile nel kernel non significa automaticamente che ogni sistema Linux sia sfruttabile. Per lo scenario di guest-to-host escape, un requisito importante è la presenza della nested virtualization, che deve essere abilitata sull’host e resa disponibile alla macchina virtuale L1. Il problema interessa il codice KVM x86 e la vulnerabilità è presente nel kernel Linux da circa il 2020, con l’introduzione del codice interessato.

La correzione è stata integrata upstream nel luglio 2026. Il ricercatore Hyunwoo Kim ha inoltre pubblicato i dettagli di Zapscape: il codice e ulteriori informazioni sono disponibili nello stesso repository GitHub di Zapscape. Lo stesso ricercatore, ha pubblicato mesi fa un’altra vulnerabilità guest-to-host altrettanto grave, Januscape, che abbiamo già trattato in un altro articolo.

La vulnerabilità è stata corretta nel kernel Linux attraverso un controllo che verifica la validità della root della MMU dopo aver reso disponibili le pagine utilizzate dalla MMU. Il punto importante, come sempre con le vulnerabilità del kernel, è verificare la presenza della correzione nel kernel distribuito dalla propria distribuzione.

I principali consigli per evitare attacchi che sfruttano questo tipo di vulnerabilità consistono nell’aggiornare il kernel degli host KVM e verificare gli advisory di sicurezza della propria distribuzione. È inoltre opportuno controllare quali host utilizzano la nested virtualization e disabilitarla dove non necessaria. Inoltre, i permessi di /dev/kvm vanno verificati con particolare attenzione, soprattutto sui sistemi dove l’accesso è consentito a utenti non privilegiati. In ambienti che ospitano workload non affidabili o multi-tenant è consigliabile dare priorità agli aggiornamenti. In caso di possibile compromissione dell’host, è inoltre opportuno valutare la rotazione delle credenziali e dei segreti presenti sul sistema. Un controllo rapido dei permessi di /dev/kvm può essere effettuato con:

ls -l /dev/kvm

L’obiettivo è verificare chi può interagire con il dispositivo e se questa configurazione è realmente necessaria.

Questa storia l’abbiamo già vista, Zapscape è l’ennesima use-after-free nel kernel, in una componente privilegiata, che apre la porta alla compromissione totale del sistema. Che si parli di guest-to-host escape o di escalation locale, il risultato (purtroppo) è quasi sempre lo stesso: l’attaccante prende il controllo totale dell’host.