// 1 CRITICAL · 4 ZERO-DAY · 7 CVE · 6 EXPLOIT NELLE ULTIME 24H
Tre vulnerabilità critiche colpiscono vCenter ed ESXi. Due permettono l'accesso senza credenziali, una consente l'escape dalla macchina virtuale all'host. Nessuna

Broadcom ha pubblicato il 29 luglio 2026 l'aggiornamento di sicurezza VMSA-2026-0006 che corregge cinque vulnerabilità nel perimetro VMware, tre delle quali classificate critiche. Due riguardano vCenter e permettono rispettivamente il bypass dell'autenticazione e l'esecuzione di codice remoto a un attore con semplice accesso di rete; la terza consente l'escape da macchina virtuale all'host ESXi attraverso l'adattatore di rete paravirtualizzato VMXNET3. Non esistono workaround per le due falle più gravi di vCenter: l'unica mitigazione documentata è l'applicazione immediata delle patch.

Punti chiave
  • CVE-2026-59309 e CVE-2026-59310 colpiscono vCenter con CVSS 9.8: il primo permette il bypass dell'autenticazione, il secondo esecuzione arbitraria di codice tramite directory traversal nel server Syslog.
  • CVE-2026-47876, con CVSS 9.3, è una scrittura fuori limiti nell'adattatore VMXNET3 che consente a un amministratore locale della VM di eseguire codice sull'host ESXi.
  • Broadcom non ha rilevato prove di exploit in-the-wild per nessuna delle cinque vulnerabilità.
  • Gli aggiornamenti correttivi coprono versioni specifiche di vCenter, ESXi, Workstation e Fusion; per le due falle critiche di vCenter non esistono contromisure alternative alla patch.

Il doppio assalto a vCenter: autenticazione annullata e codice remoto

La coppia di vulnerabilità CVE-2026-59309 e CVE-2026-59310 espone il piano di gestione centralizzato di VMware a rischi di gravità massima. La prima, scoperta dai ricercatori Phil Brass e Matt South di Atredis Partners, interessa il VMware Directory Service di vCenter: un attore con accesso di rete al sistema può aggirare completamente il meccanismo di autenticazione senza disporre di credenziali valide. Il secondo difetto, sempre nel perimetro di vCenter, risiede nel server Syslog e sfrutta una vulnerabilità di directory traversal per consentire l'esecuzione di codice arbitrario.

Entrambe le falle portano il punteggio CVSS 9.8 sulla scala v3, il valore più alto presente in questo advisory. La loro combinazione è particolarmente insidiosa: il bypass autenticativo apre la porta al pannello di amministrazione, mentre la directory traversal nel Syslog server offre un vettore per l'esecuzione di payload sull'infrastruttura sottostante. Il requisito comune è ridotto all'osso: accesso di rete a vCenter, senza privilegi pregressi né interazione con l'utente.

"A malicious actor with network access to vCenter may exploit this issue to bypass authentication and gain unauthorized access to the system" — Broadcom, advisory VMSA-2026-0006 su CVE-2026-59309

VMXNET3 tornato bersaglio: l'escape dalla VM all'host ESXi

La terza vulnerabilità critica, CVE-2026-47876, rappresenta una minaccia di natura diversa ma altrettanto grave per l'architettura di virtualizzazione. Scoperta da Nguyen Hoang Thach di STARLabs SG nel contesto Pwn2Own, mediato da Zero Day Initiative, è una scrittura fuori limiti nell'implementazione dell'adattatore di rete paravirtualizzato VMXNET3. Il difetto permette a un attore che disponga già di privilegi amministrativi all'interno di una macchina virtuale di eseguire codice sull'host ESXi che la ospita.

Il punteggio CVSS 9.3 riflette la severità del compromesso: l'isolamento tra guest e host, principio fondamentale della virtualizzazione, viene meno. Questo scenario è particolarmente rilevante per gli ambienti multi-tenant e i provider di cloud che affidano la separazione dei carichi di lavoro proprio al confine VM/ipervisore. L'advisory di Broadcom specifica che il difetto interessa esclusivamente le VM configurate con l'adattatore VMXNET3: altri controller di rete non sono toccati.

Cosa fare adesso

  • Applicare immediatamente gli aggiornamenti correttivi per vCenter alle versioni 9.1.0.0300, 9.0.2.0100 o 8.0 U3k, secondo la versione in uso; non esistono workaround per CVE-2026-59309 e CVE-2026-59310.
  • Aggiornare gli host ESXi alle build 9.1.0.0200-25557999, 9.0.2.0100-25595025 o 8.0 U3k-25595708 per chiudere la via di escape VMXNET3.
  • Verificare che le macchine virtuali eseguano l'adattatore di rete corretto: solo VMXNET3 è interessata da CVE-2026-47876, ma la verifica della configurazione è necessaria per prioritizzare gli interventi.
  • Limitare la superficie di esposizione di vCenter applicando segmentazione di rete che restringa l'accessibilità ai soli sistemi di gestione autorizzati, dato che entrambe le falle critiche richiedono solo connettività IP.

Le altre due falle e i riconoscimenti ai ricercatori

Oltre alle tre criticità, l'advisory VMSA-2026-0006 corregge CVE-2026-41703, una lettura fuori limiti in ESX/Workstation/Fusion con impatto su disclosure informativa o denial of service, valutata 7.6 per ESX e 2.7 per Workstation/Fusion. La quinta falla, CVE-2026-41709, scoperta da Ian Barton di CrowdStrike, è una carenza di logging in ESX con punteggio 2.7 che consente a un amministratore malevolo di eseguire operazioni non tracciate.

I crediti di scoperta riflettono la maturità del programma di bug bounty e responsibile disclosure di Broadcom: Atredis Partners per le falle di vCenter, STARLabs SG per l'escape VMXNET3, Maxim Suhanov per CVE-2026-41703, e CrowdStrike per la carenza di logging.

Perché il perimetro di rete non basta più

La lettura tecnica di questo advisory supera il mero elenco di CVE. Le due falle di vCenter dimostrano che il piano di gestione della virtualizzazione resta una superficie d'attacco ad alta intensità: la possibilità di bypassare l'autenticazione con la sola presenza sulla rete smonta l'assunto per cui l'isolamento di livello tre sia sufficiente a proteggere le console amministrative. In ambienti dove vCenter è raggiungibile da segmenti interni potenzialmente compromessi, la falla equivale a una chiave universale.

D'altra parte, CVE-2026-47876 conferma che l'emulazione hardware di rete paravirtualizzata è un campo di battaglia persistente. Il VMXNET3 era già stato al centro di ricerche precedenti su escape di virtualizzazione; il ritorno di questo componente come vettore critico suggerisce che la complessità dei driver paravirtualizzati continui a superare le capacità di difesa offerte dai tradizionali audit di sicurezza. Per le organizzazioni che affidano alla virtualizzazione la segregazione dei carichi sensibili, il confine VM/host non può più essere considerato invalicabile per default.

Fonti

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti


Fonti e riferimenti
  1. thehackernews.com
  2. securityweek.com
  3. cyberpress.org
  4. securityaffairs.com
  5. cybersecuritynews.com
  6. gbhackers.com
  7. support.broadcom.com
  8. resecurity.com