Se gestisci VMware vCenter, CVE-2026-59310 va trattata come una patch urgente. La vulnerabilità colpisce il server Syslog di vCenter, ha gravità critica con CVSS 9.8 e può consentire a un attaccante con accesso di rete di eseguire codice arbitrario. Broadcom non indica workaround: la correzione richiede l’aggiornamento a una build sicura.
Il rischio non è soltanto teorico. CVE-2026-59310 è stata aggiunta al catalogo Known Exploited Vulnerabilities di CISA il 18 agosto 2026. Inoltre, report di incident response hanno collegato lo sfruttamento della falla a compromissioni di vCenter e, in almeno alcuni ambienti, alla distribuzione di ransomware derivato da Babuk sugli host ESXi.

CVE-2026-59310: quali versioni di vCenter devi aggiornare
Il riferimento principale è l’advisory Broadcom VMSA-2026-0006, pubblicato il 29 luglio e aggiornato il 19 agosto 2026. Broadcom descrive CVE-2026-59310 come una directory traversal nel server Syslog di vCenter che può essere sfruttata da un attaccante raggiungibile via rete per ottenere esecuzione di codice.
| Ramo vCenter | Versione corretta indicata da Broadcom | Azione |
|---|---|---|
| 9.1.x | 9.1.0.0300 | Aggiorna a questa build o successiva |
| 9.0.x | 9.0.2.0100 | Aggiorna a questa build o successiva |
| 8.0 ramo U3 | 8.0 U3k | Installa la patch prevista per il ramo |
| 8.0 ramo U2 | 8.0 U2f | Installa la patch prevista per il ramo |
| 7.0 | Supporto esteso | Contatta Broadcom se hai un contratto Extended Support |
Non basta controllare la versione principale. Su vCenter 8.0 conta anche il livello Update e la build effettivamente installata. Se l’ambiente fa parte di VMware Cloud Foundation, vSphere Foundation o delle piattaforme Telco indicate nell’advisory, segui la matrice di risposta specifica del prodotto.
Perché la falla è pericolosa
vCenter è il piano di gestione dell’infrastruttura VMware. Una compromissione non equivale a perdere una singola macchina virtuale: può aprire la strada verso credenziali, configurazioni, datastore e host ESXi gestiti dal server.
La vulnerabilità non richiede l’interazione di un utente e Broadcom specifica che non esiste un workaround ufficiale. Ridurre l’esposizione di rete del management plane è una misura sensata, ma non sostituisce la patch.
Il 18 agosto CISA ha inserito CVE-2026-59310 nel proprio Known Exploited Vulnerabilities Catalog. L’inserimento nel KEV significa che esistono evidenze di sfruttamento nel mondo reale e rende il controllo delle build una priorità per gli ambienti esposti.
CVE-2026-59310 è usata nei ransomware?
Esistono report pubblici che collegano la campagna di sfruttamento a ransomware derivato da Babuk, ma il dettaglio va letto con precisione. CISA conferma lo sfruttamento della vulnerabilità tramite l’inserimento nel KEV; il collegamento con Babuk e i numeri della campagna provengono invece da report di incident response e threat intelligence.
Le ricostruzioni pubbliche parlano di un attore sospettato di avere legami con la Cina, di centinaia di indirizzi IP compromessi in decine di Paesi e di persistenza tramite backdoor, reverse SSH e modifiche ai servizi di sistema. In alcuni ambienti ESXi sarebbero comparsi file cifrati con estensione associata a codice ransomware derivato da Babuk.
Il punto operativo non dipende dall’attribuzione: se vCenter è rimasto vulnerabile dopo la pubblicazione della patch, non è sufficiente aggiornare e chiudere il ticket senza verificare possibili segnali di compromissione.

Cosa controllare dopo l’aggiornamento
- Verifica la build finale di vCenter e confrontala con la matrice Broadcom.
- Controlla gli accessi amministrativi e gli account creati o modificati durante il periodo di esposizione.
- Esamina log e attività anomale sul vCenter Server Appliance.
- Verifica modifiche sospette a cron, servizi systemd e meccanismi di persistenza.
- Cerca connessioni SSH o tunnel in uscita non previsti.
- Controlla gli host ESXi gestiti, soprattutto se vCenter era esposto a reti non fidate.
- Ruota credenziali e segreti se emergono indicatori concreti di accesso non autorizzato.
La sequenza è importante: la patch impedisce nuovi sfruttamenti della vulnerabilità, ma non elimina automaticamente un accesso ottenuto prima dell’aggiornamento. Se trovi indicatori sospetti, il caso va gestito come un possibile incidente e non come un semplice aggiornamento software.
Se vCenter non è esposto a Internet sei al sicuro?
No. Ridurre l’esposizione esterna abbassa il rischio, ma Broadcom descrive il requisito come accesso di rete a vCenter, non necessariamente accesso diretto da Internet. Un attaccante già presente nella rete aziendale può cercare di raggiungere il management plane da un sistema compromesso.
Per questo conviene limitare l’accesso a vCenter alle sole reti di amministrazione necessarie, applicare segmentazione e controllare che le interfacce di gestione non siano raggiungibili da segmenti utente o servizi che non ne hanno bisogno. Queste misure riducono la superficie d’attacco, ma non sono un’alternativa alla versione corretta.
Perché il rischio su VMware va letto a livello di cluster
I ransomware prendono di mira gli ambienti di virtualizzazione perché compromettere il livello di gestione può moltiplicare l’impatto. Nel nostro approfondimento su Akira e gli attacchi contro infrastrutture VMware ESXi abbiamo già visto come gli operatori ransomware abbiano spostato l’attenzione dai singoli endpoint agli hypervisor e ai sistemi centrali.
La stessa logica vale per altre appliance critiche: quando una falla consente accesso remoto a un sistema di gestione, il tempo di patch diventa decisivo. È il motivo per cui abbiamo seguito anche lo sfruttamento di Cisco FMC CVE-2026-20079, un caso diverso ma con lo stesso principio di fondo: aggiornare e poi verificare se l’ambiente fosse già stato raggiunto.
Checklist rapida per CVE-2026-59310
| Controllo | Decisione |
|---|---|
| vCenter sotto la build corretta | Aggiorna subito |
| Workaround disponibile | No |
| vCenter accessibile da reti non fidate | Priorità massima e riduzione dell’esposizione |
| Patch installata dopo un periodo di esposizione | Controlla log, account e persistenza |
| Indicatori sospetti presenti | Avvia incident response e verifica ESXi |
| vCenter 7.0 | Verifica Extended Support con Broadcom |
La decisione pratica è netta: se la tua installazione rientra nelle versioni vulnerabili, applica la build corretta indicata da Broadcom e verifica l’ambiente dopo la patch. CVE-2026-59310 è critica, non ha workaround ed è già associata a sfruttamento reale; lasciare vCenter vulnerabile espone il punto da cui viene amministrata una parte molto più ampia dell’infrastruttura.