Il 29 luglio 2026 Broadcom ha rilasciato l'aggiornamento di sicurezza VMSA-2026-0006 per VMware vCenter. Il 3 agosto, appena cinque giorni dopo, Quirso ha rilevato la prima exploitation in-the-wild di CVE-2026-59310, una vulnerabilità di directory traversal con punteggio CVSS 9.8. Entro il 5 agosto erano già oltre 360 indirizzi IP victim in 47 paesi. La finestra tra disclosure e compromissione si è ridotta a un intervallo incompatibile con i cicli di patching tradizionali.
- CVE-2026-59310 è una vulnerabilità di directory traversal nel Syslog server di VMware vCenter con CVSS 9.8, che consente RCE non autenticato [FONTE 6]
- L'exploitation in-the-wild è iniziata il 3 agosto 2026, 5 giorni dopo la disclosure del patch del 29 luglio, con oltre 360 IP victim in 47 paesi entro il 5 agosto [FONTE 1, FONTE 4]
- Gli attaccanti hanno deployato il framework open-source reverse_ssh per mantenere persistenza outbound, bypassando i controlli firewall inbound [FONTE 1]
- Quirso classifica l'attore come APT; la correlazione tempistica tra disclosure e exploitation indica il reverse-engineering del patch come punto di partenza probabile [FONTE 1]
Il meccanismo: dal Syslog server al controllo dell'infrastruttura
La vulnerabilità risiede nel Syslog server di vCenter, un componente che normalmente gestisce il logging di sistema. Secondo l'advisory Broadcom VMSA-2026-0006.1, un attore con accesso di rete al server vCenter può sfruttare il difetto di directory traversal per scrivere file arbitrari e da lì eseguire codice remoto. La condizione di attacco è non autenticata: non servono credenziali valide, basta raggiungibilità di rete.
La gravità del difetto è massima. Il punteggio CVSS 3.1 è 9.8, con vettore AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H: attacco da rete, complessità bassa, nessun privilegio richiesto, nessuna interazione utente, impatto totale su riservatezza, integrità e disponibilità. Secondo le release notes ufficiali, le versioni che correggono il difetto sono 9.1.0.0300, 9.0.2.0100, 8.0 U3k e 8.0 U2f [FONTE 6]. Broadcom ha pubblicato un aggiornamento espressivo l'8.0 U2f il 3 agosto, in risposta all'attività offensiva osservata [FONTE 4].
Rapid7, nella sua analisi del 30 luglio pubblicata prima dell'exploitation, aveva già segnalato l'urgenza massima. Il motivo non era solo il CVSS 9.8, ma la storia di VMware vCenter come bersaglio privilegiato: il prodotto è comparso nella Known Exploited Vulnerabilities list di CISA per dieci volte in passato [FONTE 3]. Quando un sistema di management della virtualizzazione viene compromesso, l'impatto non si limita al singolo server. Il controllo del piano di gestione equivale al controllo dell'intero data center virtualizzato.
L'exploitation: velocità e scala senza precedenti
I dati raccolti da Quirso e riportati da SecurityWeek e InfoSecurity Magazine disegnano una campagna rapida e geometrica. La prima compromissione è stata osservata il 3 agosto 2026. Due giorni dopo, entro il 5 agosto, circa il 95% dei 361 indirizzi IP totali era già stato colpito [FONTE 4]. La distribuzione geografica mostra una concentrazione: la metà delle victim IP si trova in cinque paesi, Germania, Stati Uniti, Turchia, Iran e Francia [FONTE 1].
"A malicious actor with network access to vCenter may exploit this issue to execute arbitrary code" — Broadcom advisory VMSA-2026-0006.1
Quirso ha esplicitamente limitato l'interpretazione: un indirizzo IP non corrisponde necessariamente a un'organizzazione o a un sistema fisico unico. Il numero esatto di entità compromise rimane incerto [FONTE 1]. Ciò che è documentato è la velocità di propagazione: un arco di 48 ore per raggiungere la quasi totalità del campione osservato. Questa dinamica esclude ipotesi di targeting manuale e suggerisce un'automazione della compromissione.
Il dual-clock problem: due orologi da sincronizzare
La risposta tecnica alla disclosure del 29 luglio ha seguito il paradigma consolidato: applicare il patch, verificare la versione, chiudere la vulnerabilità. La campagna del 3 agosto ha reso questo paradigma insufficiente. Esiste ormai un problema di dual clock, come ha formulato Jason Soroko di Sectigo citato da InfoSecurity Magazine: un orologio per chiudere la vulnerabilità, un altro per espellere chi è entrato prima del patch [FONTE 4].
Il framework reverse_ssh, rilevato da Quirso nelle compromissioni, illustra perché il secondo orologio sia più difficile da gestire. Non si tratta di un malware sofisticato o proprietario, ma di uno strumento open-source legittimo di penetration testing, riadattato per mantenere una connessione di controllo outbound. Il vantaggio per l'attaccante è architetturale: una reverse shell SSH in uscita bypassa i firewall perimetrali che bloccano il traffico in ingresso, e il traffico cifrato si confonde con le connessioni SSH legittime [FONTE 1].
La persistenza outbound rende l'indicatore di compromissione più elusivo. Non basta verificare che il patch sia applicato: è necessario cercare processi anomali, connessioni SSH uscenti verso endpoint non autorizzati, job di persistenza nel sistema operativo sottostante. Il brief non documenta entità di post-compromissione oltre il reverse shell, né l'obiettivo finale dell'attore: ransomware, spionaggio, sabotaggio o movimento laterale verso altri target rimangono non dichiarati.
Perché vCenter resta il bersaglio privilegiato
La virtualizzazione ha centralizzato il rischio. VMware vSphere e il suo piano di gestione vCenter sono progettati per amministrare migliaia di host e macchine virtuali da un'unica console. Questa architettura, efficiente per l'operatività, concentra anche la superficie d'attacco. Secondo l'analisi di hard2bit, vCenter rappresenta un single point of compromise per l'infrastruttura IT aziendale [FONTE 5]. La documentazione non specifica se l'advisory consideri scenari di esposizione internet diretta o solo accesso da rete interna; il vettore di attacco AV:N nel CVSS indica raggiungibilità di rete senza ulteriori specificazioni sul perimetro.
Il costo per l'attaccante è basso: accesso di rete, nessuna autenticazione, exploit presumibilmente derivato dal reverse-engineering del patch. L'impatto è catastrofico: controllo del piano di gestione, potenziale accesso a tutte le VM ospitate, capacità di modificare configurazioni di rete, storage e backup. L'economia dell'attacco spiega la velocità di adozione post-disclosure e la preferenza degli attori APT per questa classe di target.
Cosa fare adesso
Le azioni operative derivano direttamente dai fatti documentati nel brief:
- Verificare la versione di VMware vCenter in uso e applicare il patch alle versioni fix 9.1.0.0300, 9.0.2.0100, 8.0 U3k o 8.0 U2f secondo le release notes ufficiali Broadcom [FONTE 6]
- Assumere compromissione se il sistema era esposto tra il 29 luglio e il momento dell'applicazione del patch, data l'exploitation confermata dal 3 agosto [FONTE 1]
- Ricercare indicatori di persistenza outbound, in particolare processi associati al framework reverse_ssh o connessioni SSH anomale in uscita dai server vCenter [FONTE 1]
- Considerare la segmentazione di rete per limitare la raggiungibilità del Syslog server vCenter solo agli host autorizzati, dato che non esistono workaround alternativi al patch [FONTE 6]
Il brief non documenta misure correttive specifiche oltre al patching, né fornisce dettagli su eventuali controlli di integrità pre e post-applicazione dell'aggiornamento.
Domande frequenti
Esistono workaround per CVE-2026-59310?
No. L'advisory Broadcom VMSA-2026-0006.1 elenca esplicitamente "Workarounds: None" per entrambi i CVE critici inclusi nel bollettino [FONTE 6]. L'unica mitigazione documentata è l'aggiornamento a una versione corretta.
Può un IP victim corrispondere a più organizzazioni?
Sì. Quirso ha esplicitamente dichiarato che non è possibile inferire il numero esatto di organizzazioni compromise dagli indirizzi IP rilevati, poiché un IP non corrisponde necessariamente a un'unica entità o sistema fisico [FONTE 1]. Il dato di 360+ IP è quindi una misura di scala dell'attività, non un conteggio organizzativo.
È stato usato un exploit zero-day?
Non è documentato. Quirso suggerisce che la forte correlazione tra disclosure e exploitation indichi il reverse-engineering del patch come punto di partenza della campagna, piuttosto che la disponibilità pre-disclosure di un exploit [FONTE 1]. Il brief non conferma né esclude l'esistenza di accesso zero-day pre-29 luglio.
Fonti
- https://www.securityweek.com/critical-vmware-vcenter-vulnerability-in-attackers-crosshairs/
- https://www.rapid7.com/blog/post/etr-critical-vmware-vcenter-vulnerabilities-allow-authentication-bypass-and-remote-code-execution-cve-2026-59309-cve-2026-59310/
- https://www.infosecurity-magazine.com/news/vcenter-cve-2026-59310-exploited/
- https://hard2bit.com/en/blog/vmware-vcenter-esxi-vmsa-2026-0006-critical-flaws-patch/
- https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/38017
- http://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/38017
- https://podcast.securityweek.com/
Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.