Broadcom ha rilasciato il 29 luglio 2026 cinque patch per vulnerabilità in VMware vCenter, ESXi, Workstation e Fusion. Tre di queste falle sono classificate critiche, con punteggi CVSS fino a 9.8, e consentono a un attaccante di aggirare l'autenticazione, eseguire codice arbitrario su vCenter o forzare l'escape da macchina virtuale verso l'host ESXi. La stessa correzione introduce una restrizione operativa non prevista: l'impossibilità di aggiornare a VMware Cloud Foundation e vSphere Foundation 9.0 e 9.1 dalle versioni precedenti, un effetto collaterale che complica la roadmap degli amministratori.
- Tre vulnerabilità critiche con CVSS 9.8, 9.8 e 9.3 colpiscono vCenter e ESXi: bypass autenticazione, RCE e VM escape
- Nessuno sfruttamento noto al momento, ma Broadcom non indica workaround alternativi alle patch
- CVE-2026-41709 presenta una discrepanza nel punteggio CVSS tra fonti: 2.7 secondo HWUpgrade, 7.6 secondo SecurityAffairs
- La patch introduce una restrizione "back in time" che blocca gli upgrade a VCF/vSphere Foundation 9.0 e 9.1 dalle versioni precedenti
Il nucleo offensivo: autenticazione bypass e RCE su vCenter
Due delle tre falle critiche risiedono in vCenter, il pannello di gestione centralizzata dell'infrastruttura virtualizzata. CVE-2026-59309 è un bypass dell'autenticazione nel VMware Directory Service con CVSS 9.8: un attaccante con accesso di rete ottiene accesso non autorizzato al sistema. Secondo l'advisory Broadcom citato da SecurityAffairs, "a malicious actor with network access to vCenter may exploit this issue to bypass authentication and gain unauthorized access to the system".
CVE-2026-59310, anch'essa con CVSS 9.8, sfrutta un directory traversal nel vCenter Syslog Server per eseguire codice arbitrario. Anche in questo caso l'attaccante richiede solo accesso di rete, senza autenticazione preventiva. L'advisory Broadcom, riportato da SecurityAffairs, precisa che il vettore permette di "execute arbitrary code".
La combinazione di queste due falle espone il livello di orchestrazione dell'infrastruttura: chi controlla vCenter controlla il cluster. La superficie di attacco è esposta a rete, senza prerequisiti di privilegi o interazione utente.
VM escape su ESXi: dalla macchina virtuale all'host
La terza vulnerabilità critica, CVE-2026-47876 con CVSS 9.3, colpisce l'adattatore di rete virtuale VMXNET3 su ESXi. Si tratta di una scrittura out-of-bounds che consente a un attaccante con privilegi amministrativi locali su una macchina virtuale di eseguire codice sull'host fisico. L'advisory Broadcom, citato da SecurityAffairs, specifica che "a malicious actor with local administrative privileges on a virtual machine with VMXNET3 virtual network adapter may exploit this issue to execute code on the host".
Il meccanismo è diverso dalle due falle su vCenter: qui l'attaccante deve già controllare una VM, ma il risultato è il controllo dell'hypervisor. Il punteggio CVSS 9.3 riflette la gravità dell'impatto combinato con la necessità di accesso locale privilegiato. Per ambienti multi-tenant o con macchine virtuali gestite da terze parti, la catena di escalation è concreta.
Le versioni corrette sono, secondo HWUpgrade: vCenter 9.1.0.0300, 9.0.2.0100 e 8.0 Update 3k; ESXi 9.1.0.0200, 9.0.2.0100 e 8.0 Update 3k.
Le altre due falle e la discrepanza su CVE-2026-41709
Oltre alle tre critiche, Broadcom ha corretto CVE-2026-41703 e CVE-2026-41709. La prima ha impatto differenziato per prodotto: su ESXi presenta CVSS 7.6 per disclosure informazioni e condizioni di denial of service, mentre su Workstation e Fusion scende a CVSS 2.7 per disclosure limitata.
CVE-2026-41709, relativa alla creazione di macchine virtuali da CLI senza visibilità in interfaccia grafica o log, presenta una discrepanza tra fonti. HWUpgrade riporta CVSS 2.7, mentre SecurityAffairs indica 7.6. Il dossier non risolve il conflitto: la natura esatta del rischio associato a questa vulnerabilità resta da verificare.
Broadcom conferma attraverso più fonti — HWUpgrade, Field Effect, SecurityWeek, SecurityAffairs — che non risulta sfruttamento in-the-wild al momento della pubblicazione.
Il dilemma operativo: sicurezza o roadmap?
Le patch risolvono le falle, ma introducono una restrizione operativa significativa. Secondo Broadcom, citato da HWUpgrade, si presenta una restrizione "back in time" quando una patch aggiorna un prodotto a un ramo che detiene un numero di build più nuovo rispetto a quello dell'aggiornamento desiderato. Il risultato pratico: è attualmente impossibile effettuare il passaggio a VMware Cloud Foundation e vSphere Foundation 9.0 e 9.1 dalle versioni precedenti.
Questo effetto collaterale non è una vulnerabilità di sicurezza, ma una condizione di blocco infrastrutturale. Per gli amministratori che avevano pianificato upgrade verso la release 9.x, la scelta si restringe a due opzioni non ottimali: rimanere su release precedenti senza la protezione delle patch più recenti, oppure applicare la patch e rinviare la migrazione.
"A malicious actor with network access to vCenter may exploit this issue to bypass authentication and gain unauthorized access to the system" — Broadcom advisory, riportato da SecurityAffairs
Cosa fare adesso
Gli amministratori devono applicare le patch nelle versioni indicate da Broadcom: vCenter 9.1.0.0300, 9.0.2.0100 o 8.0 Update 3k; ESXi 9.1.0.0200, 9.0.2.0100 o 8.0 Update 3k. Non esistono workaround documentati per nessuna delle cinque vulnerabilità, quindi il patching è l'unico controllo disponibile.
Va verificata la pianificazione degli upgrade a VCF 9.0 o 9.1: se l'ambiente è candidato alla migrazione, la restrizione "back in time" impone una revisione della sequenza temporale. Gli operatori devono controllare il livello di build corrente rispetto alla release target.
Per CVE-2026-47876, va valutata la superficie esposta delle VM con adattatore VMXNET3 e il profilo di accesso amministrativo su quelle macchine. Non è documentata un'indicazione di workaround di rete o di microsegmentazione.
Su CVE-2026-41709, la discrepanza CVSS tra fonti suggerisce di attendere chiarimenti ufficiali prima di classificarne il rischio in modo definitivo.
Lettura: la trappola del patching forzato
Il caso Broadcom-VMware illustra una tensione strutturale nel software enterprise: la velocità della correzione di sicurezza può confliggere con la prevedibilità della roadmap prodotto. Quando una patch modifica il numero di build in modo da invalidare upgrade futuri, il patching non è più una scelta tecnica isolata ma una decisione architetturale. Gli amministratori si trovano a gestire un trade-off che il vendor non ha risolto in anticipo.
La mancanza di workaround per tutte e cinque le vulnerabilità amplifica la pressione: non è possibile mitigare temporaneamente con controlli compensativi. L'unica leva operativa è la sequenza temporale dell'applicazione, che però incide sulla disponibilità del percorso di upgrade. Per infrastrutture regolate o con finestre di manutenzione vincolate, la combinazione di criticità elevata e rigidità operativa costituisce un vincolo di progetto non trascurabile.
Fonti
- https://edge9.hwupgrade.it/news/security/broadcom-rilascia-patch-per-cinque-vulnerabilita-in-prodotti-vmware-di-cui-tre-definite-critiche_157153.html
- https://fieldeffect.com/blog/broadcom-patches-critical-vcenter-vulnerabilities
- https://www.securityweek.com/critical-vm-escape-vulnerability-patched-in-vmware-esxi/
- https://securityaffairs.com/196231/security/broadcom-patches-critical-vmware-esxi-vulnerability-enabling-host-code-execution.html
- https://resecurity.com/
Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.