C’è una categoria di notizie di sicurezza che il titolare di una piccola impresa scorre e archivia come «roba da informatici». Questa lo sembra, ma non lo è, e vale la pena di capire perché in tre minuti.
Il 29 luglio Broadcom ha rilasciato correzioni d’emergenza per una serie di falle nei prodotti VMware: il software con cui si fanno girare più «computer» dentro un unico server fisico. Due di queste hanno punteggio 9,8 su 10. Una terza, da 9,3, permette una cosa che molti danno per impossibile: uscire da una macchina virtuale e arrivare al server che la ospita.
Perché probabilmente ti riguarda anche se non lo sai
La sala macchine di una PMI italiana media, quando c’è, è fatta quasi sempre così: un server fisico, e sopra cinque o sei macchine virtuali. Una fa girare il gestionale, una tiene i file condivisi, una la contabilità, a volte una il centralino. Sono state messe lì da un fornitore IT anni fa e da allora funzionano.
Quel «sopra» è VMware, nella stragrande maggioranza dei casi. Il titolare non lo sa perché non ha mai avuto motivo di saperlo.
La virtualizzazione viene venduta con l'idea che ogni macchina virtuale sia una stanza chiusa: se una si infetta, le altre restano al sicuro. Una vulnerabilità di tipo VM escape rompe proprio quella promessa. Chi ha accesso amministrativo a una sola macchina virtuale — poniamo, quella meno curata, con sopra un software vecchio — può arrivare al server fisico. E da lì, a tutte le altre stanze in una volta sola.
Questo è il punto pratico. Il ragionamento «quel PC virtuale è isolato, se prende qualcosa lo rifacciamo» smette di reggere: con CVE-2026-47876 — la falla nell’adattatore di rete virtuale VMXNET3, punteggio 9,3 — chi comanda dentro una macchina virtuale può eseguire codice sull’host che le ospita tutte.
Le due falle da 9,8 riguardano vCenter
Le altre due, entrambe a 9,8, colpiscono vCenter, cioè la console da cui si amministrano più host insieme:
- CVE-2026-59309 — un bypass dell’autenticazione: si entra senza credenziali valide.
- CVE-2026-59310 — un directory traversal attraverso il server Syslog, che apre all’esecuzione di codice arbitrario.
Chi ha un solo server ESXi, senza vCenter, non è toccato da queste due. Chi ha vCenter raggiungibile dalla rete aziendale, sì — e la prima delle due significa letteralmente che la password non serve.
La notizia buona, che va detta
Al momento della pubblicazione Broadcom dichiara di non avere evidenze che queste falle siano state sfruttate in attacchi reali. Non è una notizia da panico e non c’è nessun motivo di spegnere i server stanotte.
È però una di quelle cose che invecchiano male: quando il dettaglio tecnico diventa pubblico, il tempo che serve a costruire un attacco funzionante si misura in giorni, non in mesi. La finestra utile per muoversi con calma è adesso.
Cosa fare, concretamente
Non sei tu a dover applicare la patch. Sei tu a dover fare in modo che qualcuno la applichi, e a farti dire quando.
- Capisci se ti riguarda. La domanda da fare a chi ti gestisce l’IT è una sola: «Il nostro server è virtualizzato con VMware? Se sì, con quale versione, e abbiamo vCenter?» Se la risposta è no, hai finito.
- Se la risposta è sì, chiedi l’aggiornamento in forma esplicita, non come «dai un’occhiata». Le versioni correttive indicate sono Cloud Foundation e vSphere Foundation 9.1.0.0300 e 9.0.2.0100, vCenter 8.0 U3k, e Workstation e Fusion 26H1.
- Fatti dare una data. «Ci pensiamo noi» non è una data. Se il fornitore ha bisogno di una finestra di fermo, concordala: mezz’ora di gestionale spento vale meno di quello che c’è dall’altra parte.
- Chiedi se vCenter è raggiungibile da internet. Se lo è, e non c’è un motivo forte perché lo sia, quella è una cosa da chiudere a prescindere da questa notizia.
Se in azienda c'è un unico server fisico virtualizzato, quasi certamente hai solo ESXi: ti riguarda la falla da 9,3, quella della fuga dalla macchina virtuale, e serve comunque la patch. Se hai due o più host amministrati da una console centrale, hai anche vCenter: allora rientrano pure le due falle da 9,8, e la priorità sale, perché una delle due consente l'accesso senza password.
In breve
Broadcom ha pubblicato il 29 luglio correzioni d’emergenza per VMware: CVE-2026-59309 e CVE-2026-59310 su vCenter, entrambe 9,8, la prima consente di entrare senza credenziali; CVE-2026-47876 su VMXNET3, 9,3, consente di passare da una macchina virtuale al server fisico che la ospita. Non ci sono workaround, e Broadcom non ha evidenze di sfruttamento in corso.
Se il gestionale della tua azienda gira su un server virtualizzato — cosa vera per moltissime PMI italiane, spesso senza che il titolare lo sappia — la cosa da fare oggi è una telefonata al fornitore IT, con una domanda precisa e la richiesta di una data.