Il 29 luglio 2026 Broadcom ha corretto CVE-2026-59310, una falla con CVSS 9,8 nel server Syslog di VMware vCenter Server. Il difetto consente esecuzione di codice a chi raggiunge il sistema via rete ed è già oggetto di sfruttamento attivo. Poiché vCenter governa host ESXi e macchine virtuali, l’impatto può superare rapidamente il singolo server.
In breve
- Broadcom ha pubblicato l’advisory VMSA-2026-0006 e la patch il 29 luglio.
- CISA ha inserito la vulnerabilità nel catalogo Known Exploited Vulnerabilities il 18 agosto.
- I primi tentativi di sfruttamento sarebbero comparsi dal 3 agosto.
- QUIRSO rileva 361 indirizzi IP compromessi in 47 Paesi.
- Non esiste un workaround ufficiale: serve installare la build corretta.
Sommario
CVE-2026-59310: la falla critica di vCenter è già sfruttata
La vulnerabilità critica riguarda una directory traversal nel server Syslog di VMware vCenter Server. Un attaccante con raggiungibilità di rete può sfruttarla per eseguire codice sul sistema, senza che l’accesso debba partire necessariamente da Internet.
Il rischio interessa la gestione della virtualizzazione. vCenter coordina configurazioni, credenziali, datastore e host virtualizzati ESXi: un’intrusione nel piano di gestione può offrire una posizione privilegiata per espandere l’accesso all’ambiente.
Broadcom include nella propria matrice di correzione VMware vCenter Server, VMware Cloud Foundation e VMware vSphere Foundation. La sola limitazione dell’esposizione esterna riduce la superficie d’attacco, ma non risolve il problema se un sistema interno già compromesso riesce a raggiungere il management plane.
Dalla patch di luglio al KEV di CISA: la cronologia
L’aggiornamento alla build corretta va trattato come un’azione prioritaria perché la finestra tra patch e attacchi è stata breve. Broadcom ha pubblicato VMSA-2026-0006 il 29 luglio 2026; secondo shattered.io, le prime attività malevole sono state osservate il 3 agosto.
| Data | Evento |
|---|---|
| 29 luglio | Broadcom pubblica advisory e patch |
| 3 agosto | Emergono i primi tentativi di sfruttamento |
| 5 agosto | Risultano già compromessi 343 IP |
| 18 agosto | CISA inserisce CVE-2026-59310 nel KEV |
L’inclusione nel catalogo CISA conferma evidenze di sfruttamento reale. Non certifica invece la natura degli attacchi successivi né attribuisce automaticamente una campagna ransomware a uno specifico gruppo.
La patch blocca nuovi tentativi basati su questa vulnerabilità. Non rimuove però eventuali account, servizi o strumenti installati prima dell’aggiornamento: per questo il controllo post-patch deve entrare nella gestione dell’incidente.
Ransomware Babuk e 361 server: cosa riportano i report
Le ricostruzioni di incident response richiedono una distinzione netta dai fatti confermati da CISA. Secondo shattered.io, che riprende l’indagine della società tedesca QUIRSO, 361 indirizzi IP in 47 Paesi sarebbero stati compromessi; 343 risultavano colpiti già il 5 agosto.
I report collegano almeno alcuni ambienti alla distribuzione di ransomware derivato da Babuk sugli host ESXi. Questo legame non deriva dall’inserimento nel KEV, bensì dalle evidenze raccolte durante la risposta agli incidenti.
QUIRSO formula inoltre, con fiducia moderata, l’ipotesi di un attore con possibili legami con la Cina. Non si tratta di una conferma indipendente. Il dato operativo resta la possibile persistenza dopo l’accesso iniziale, attraverso modifiche che possono mantenere attivo il controllo dell’infrastruttura.
Aggiornare non basta: cosa verificare nell’ambiente VMware
Dopo l’installazione della build corretta, serve verificare se l’ambiente mostrava un indicatore di compromissione nel periodo di esposizione. La verifica deve coprire vCenter e gli host ESXi gestiti, poiché il controllo centralizzato può essere usato per estendere l’intrusione.
- Controllare account amministrativi creati, modificati o abilitati senza autorizzazione.
- Esaminare log di vCenter, attività di rete e accessi anomali.
- Cercare modifiche sospette a cron, servizi e meccanismi di persistenza.
- Verificare gli host ESXi collegati e l’integrità delle relative configurazioni.
- Ruotare credenziali e segreti se emergono tracce concrete di accesso illecito.
Nei prossimi controlli andrà monitorata l’eventuale pubblicazione di ulteriori indicatori tecnici da Broadcom, CISA o QUIRSO. Una conferma di compromissione richiede l’apertura immediata della procedura di incident response, non la semplice chiusura del ticket di patch.
