VMware Workstation: bug VMXNET3 con CVSS 9.3 rompe l'isolamento hypervisor

Una vulnerabilità critica nel driver VMXNET3 di VMware Workstation e Fusion, divulgata pubblicamente il 9 settembre 2026, consente a un attaccante con privilegi amministrativi locali su una macchina virtuale di eseguire codice arbitrario nel contesto dell'hypervisor host. Il problema, tracciato come CVE-2026-59346 con punteggio CVSS 9.3, è stato segnalato alla Zero Day Initiative il 26 agosto 2026 da un team di ricercatori indipendenti e rappresenta uno dei pochi veri vettori di VM escape documentati su piattaforme desktop di virtualizzazione nel 2026.

Come funziona il flaw: dall'ottimizzazione di rete alla corruzione di memoria

Il problema risiede nell'implementazione del dispositivo virtuale VMXNET3, l'adattatore di rete ad alte prestazioni che VMware offre alle macchine virtuali. Nello specifico, il difetto si manifesta durante la gestione della segmentazione TSO, una tecnica di offload che delega al NIC (Network Interface Controller) la frammentazione dei pacchetti TCP di grandi dimensioni, riducendo il carico sulla CPU.

Secondo l'advisory ZDI-26-647, la mancata validazione di dati forniti dall'utente nel contesto guest provoca un integer overflow nel calcolo della dimensione del buffer da allocare. L'overflow aritmetico produce un valore più piccolo del necessario; il sistema alloca quindi una regione di memoria insufficiente, e le operazioni successive scrivono oltre i limiti previsti, con conseguente corruzione di memoria controllabile dall'attaccante.

Questo meccanismo trasforma quella che dovrebbe essere un'ottimizzazione delle performance — la segmentazione hardware dei pacchetti — in un vettore di attacco diretto contro l'hypervisor. La natura del bug è particolarmente insidiosa perché sfrutta un percorso dati normale del driver, non una condizione di errore eccezionale.

"The specific flaw exists within the implementation of the VMXNET3 virtual device. The issue results from the lack of proper validation of user-supplied data, which can result in an integer overflow before allocating a buffer."
— TrendAI Zero Day Initiative, ZDI-26-647

Condizioni di attacco: chi può sfruttare la vulnerabilità

Entrambe le fonti primarie convergono sui requisiti di accesso. L'advisory ZDI specifica che "an attacker must first obtain the ability to execute high-privileged code on the target guest system". Broadcom, nell'advisory VMSA-2026-0007, precisa che l'attore dannoso deve disporre di "local administrative privileges on a virtual machine with VMXNET3 virtual network adapter".

Questa condizione è significativamente più accessibile di quella richiesta da molti altri bug di virtualizzazione. Non serve compromettere l'host fisico in anticipo, né interagire con l'utente dell'hypervisor. È sufficiente che l'attaccante — o un malware già presente sulla VM — esegua con privilegi elevati all'interno della macchina virtuale. In ambienti di sviluppo, testing di sicurezza o laboratori condivisi, questa condizione non è rara.

Non è chiaro dal dossier se VMXNET3 sia l'adattatore di rete predefinito per le nuove VM o se richieda una configurazione esplicita da parte dell'utente. Questa informazione mancante ha implicazioni praticate per la valutazione del rischio: se il componente vulnerabile è attivo di default, la superficie di esposizione si allarga considerevolmente.

L'impatto: il ritorno del VM escape come minaccia concreta

L'esecuzione di codice sull'host fisico rappresenta la rottura del contratto fondamentale della virtualizzazione, che presuppone isolamento rigido tra guest e hypervisor. Quando questo confine cede, tutte le VM ospitate sullo stesso host diventano potenzialmente esposte, insieme ai dati dell'hypervisor stesso e alle risorse di rete a cui l'host ha accesso.

L'advisory Broadcom enuncia direttamente che l'attaccante può "exploit this issue to execute code on the host". La ZDI aggiunge il dettaglio che l'escalation permette di "escalate privileges and execute arbitrary code in the context of the hypervisor". Questa formulazione indica non solo l'esecuzione di codice, ma il livello di privilegio massimo all'interno dello strato di virtualizzazione.

Il dossier non specifica se la vulnerabilità interessi anche configurazioni enterprise come ESXi. Entrambe le fonti si limitano a Workstation e Fusion, i prodotti desktop destinati a sviluppatori, tester e utenti professionali. L'estensione o meno del problema all'ecosistema server di VMware rimane non verificata.

Cosa fare adesso

Le azioni prioritarie derivano direttamente dai documenti di advisory:

• Applicare l'aggiornamento a VMware Workstation e Fusion versione 26H1u1, indicato da Broadcom come versione corretta nella response matrix di VMSA-2026-0007.
• Verificare quale adattatore di rete virtuale sia configurato nelle VM in uso: se VMXNET3 è attivo, la patch è obbligatoria e non esistono alternative di mitigazione intermedia.
• Considerare temporaneamente la disabilitazione di VMXNET3 in favore di adattatori di rete alternativi dove compatibili, fino all'applicazione dell'aggiornamento, dato che l'advisory indica esplicitamente "None" per i workaround.
• Monitorare gli accessi amministrativi nelle VM di sviluppo e testing, dove la condizione di attacco (privilegi locali elevati) è più probabile per natura dell'ambiente.

Perché questo bug riapre una conversazione mai chiusa

I driver di periferiche virtuali sono da tempo riconosciuti come superficie di attacco privilegiata contro gli hypervisor. Ogni volta che un sistema guest interagisce con un dispositivo emulato o paravirtualizzato, il software di traduzione tra mondi — il driver nel guest e il backend nell'hypervisor — elabora input che l'attaccante controlla direttamente. La segmentazione TSO, in particolare, richiede il parsing di metadati di dimensione pacchetto che attraversano il confine di trust senza validazione sufficiente.

Il caso CVE-2026-59346 dimostra che ottimizzazioni di performance mature e diffuse possono nascondere ipotesi di sicurezza non verificate: il presupposto che un valore di dimensione buffer, calcolato dai dati di rete, sia sempre coerente e affidabile. L'integer overflow è una classe di bug nota da decenni, ma la sua ricomparsa in un componente così centrale della stack di virtualizzazione VMware suggerisce che il problema strutturale — la complessità dei parser di periferiche virtuali — non è stato risolto definitivamente.

La natura locale del requisito di attacco non deve offrire falsa rassicurazione. In un ecosistema dove le VM vengono importate da fonti non verificate, dove gli ambienti di CI/CD esegono codice automatizzato con privilegi elevati, dove i ricercatori di sicurezza operano malware intenzionalmente nelle sandbox, il confine tra "locale alla VM" e "locale all'host" è sottile e spesso attraversato inconsapevolmente.

Fonti

• http://www.zerodayinitiative.com/advisories/ZDI-26-647/
• https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/38288

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti