vCenter, due falle da 9.8 sul piano di controllo: e Broadcom dice che non c'è un workaround

Il pezzo che tiene in piedi tutto il resto

C'è una gerarchia implicita in ogni data center virtualizzato, e raramente viene detta ad alta voce. In cima non ci sono i server applicativi, né i database, né i firewall. In cima c'è la console che decide dove girano tutti quanti. In un ambiente VMware quella console si chiama vCenter Server: da lì si amministrano gli host ESXi, le macchine virtuali, l'allocazione delle risorse, l'alta disponibilità. Chi controlla vCenter non ha compromesso un sistema. Ha compromesso il posto da cui si decide cosa fare di tutti gli altri.

Il 29 luglio 2026 Broadcom ha pubblicato l'advisory VMSA-2026-0006, che raccoglie cinque vulnerabilità distribuite fra VMware ESX, vCenter, Workstation e Fusion. Le severità individuali vanno da 2.7 a 9.8 sulla scala CVSS 3.1, e il bollettino nel suo complesso è classificato critico. Due delle cinque riguardano vCenter, ed è su quelle che vale la pena fermarsi.

Le due che contano

CVE-2026-59309 è un bypass di autenticazione nel VMware Directory Service di vCenter. Un attaccante remoto con accesso di rete al servizio vulnerabile può scavalcare i controlli di autenticazione e ottenere accesso non autorizzato al piano di gestione. Il Directory Service è il componente che risponde alla domanda "chi sei e cosa puoi fare" dentro l'infrastruttura vSphere: una falla lì non è un ingresso in una stanza, è un ingresso alla portineria.

CVE-2026-59310 è un path traversal nel server Syslog di vCenter che consente a un attaccante con accesso di rete di eseguire codice arbitrario. Vale la pena notare l'ironia operativa: il servizio che raccoglie i log — cioè lo strumento che dovrebbe permettere di accorgersi di un'intrusione — diventa il modo per eseguirla.

Entrambe hanno vettore di rete, complessità bassa, nessun privilegio richiesto e nessuna interazione dell'utente: è la combinazione che porta il punteggio a 9.8. E per entrambe Broadcom afferma che non esistono workaround, il che significa che l'unica rimedizione disponibile è la versione corretta.

Quello che non sappiamo, detto chiaramente

Al momento della pubblicazione dell'analisi di Rapid7 — il 30 luglio 2026 — non risultano né sfruttamento in-the-wild né scansioni riconducibili a queste due CVE, e non risulta codice proof-of-concept pubblico. Nessuna delle due è nel catalogo KEV della CISA: l'ultima versione del catalogo, la 2026.07.29, non le contiene.

Questa è una differenza sostanziale rispetto ai dossier di questi giorni su falle già sfruttate, e va detta invece che nascosta: oggi qui non c'è un attacco in corso, c'è una finestra. Il motivo per cui la finestra si chiude in fretta lo dice Rapid7 con un dato di contesto: vCenter Server è comparso dieci volte in KEV in passato, per altre vulnerabilità. È un prodotto che gli attaccanti guardano, e la distanza fra pubblicazione e sfruttamento su questa classe di prodotti si sta accorciando.

Il conforto che non è un rimedio

C'è un argomento che tornerà in ogni riunione dei prossimi giorni: vCenter non è esposto su internet, sta sulla rete di gestione. Nella maggior parte delle organizzazioni serie è vero, ed è una buona pratica — di quelle che restano valide anche quando non si conosce ancora la falla.

Ma va letta per quello che è. Rapid7 lo scrive esplicitamente: la restrizione alle reti interne o dedicate riduce l'esposizione agli attacchi provenienti da internet, non mitiga il rischio posto da un attaccante che si è già procurato un punto d'appoggio dentro la rete. E il punto d'appoggio dentro la rete, nella catena d'attacco tipica del 2026, è la parte facile: una credenziale rubata via phishing, una sessione intercettata, un fornitore compromesso.

Detto altrimenti: la segmentazione trasforma queste due CVE da falla perimetrale a falla di escalation. Non le disinnesca. E l'escalation, quando l'obiettivo è vCenter, arriva molto in alto molto in fretta.

1. 01
   Ingresso qualunque nella rete

   credenziale rubata, fornitore, appliance
2. 02
   Accesso di rete a vCenter

   dalla rete di gestione, se raggiungibile
3. 03
   Piano di controllo vSphere

   host ESXi, macchine virtuali, backup, snapshot

Cosa fare, in ordine

Prima cosa: sapere quali versioni avete. Le correzioni sono già disponibili. Per vCenter 9.1.x.x la versione corretta è 9.1.0.0300; per 9.0.x.x è 9.0.2.0100; per vCenter 8.0 è 8.0 U3k. Per VMware Cloud Foundation 5.x si passa da una patch asincrona alla 8.0 U3k. Per Telco Cloud Platform (3.0, 4.x, 5.0.x, 5.1.x) e Telco Cloud Infrastructure (3.0) Broadcom rimanda all'articolo di knowledge base KB449886: se avete quei prodotti, la vostra risposta è lì e non nella tabella generale.

Seconda cosa: trattarla come una patch urgente, non ordinaria. Non perché ci sia un attacco in corso, ma perché il costo di sbagliare la stima è asimmetrico. Se la finestra si chiude prima dell'exploit, avete fatto una manutenzione programmata. Se si chiude dopo, state ricostruendo la fiducia in ogni macchina virtuale che gira su quella infrastruttura.

Terza cosa: usare l'occasione per verificare la rete di gestione davvero. Non come è documentata: come è. Chi la raggiunge, da dove, con quale autenticazione. È una verifica che serve oggi per vCenter e servirà identica per il prossimo advisory su un prodotto che non avete ancora in mente.

Una nota di trasparenza sulle fonti: i dettagli tecnici, le versioni corrette e l'assenza di workaround provengono dall'advisory Broadcom e dall'analisi di Rapid7. Lo stato di non-sfruttamento è una fotografia al 30 luglio 2026 e può cambiare in qualunque momento; quando cambierà, sarà il catalogo KEV il primo posto in cui vederlo.