CVE-2026-41709: vulnerabilità ESXi sfruttata, come patchare

Il 28 ottobre 2026 CISA ha inserito CVE-2026-41709 nel catalogo Known Exploited Vulnerabilities, con scadenza di remediation fissata all’11 novembre per le agenzie federali USA. Si tratta di una vulnerabilità di VMware ESXi con punteggio CVSS di appena 2.7, corretta da Broadcom a luglio con l’advisory VMSA-2026-0006.

In quel bollettino c’erano due vulnerabilità vCenter da 9.8 e una VM escape da 9.3, quindi è facile che un “Low” da 2.7 sia finito in fondo alla lista delle priorità. Il problema è che questa vulnerabilità è stata sfruttata come zero-day, prima ancora che la patch esistesse.

In questo articolo vediamo cosa fa la vulnerabilità, quali build la correggono, come verificare i propri host e perché chi è rimasto su ESXi 8.0 Update 2 è ancora esposto anche se ha applicato le patch di agosto.

Cosa fa la vulnerabilità

Secondo Broadcom, ESXi contiene una vulnerabilità di logging insufficiente (CWE-778): un amministratore malevolo può eseguire alcune operazioni senza che vengano registrate nei log. Non esistono workaround. Broadcom non ha specificato quali operazioni sfuggono al log e non sono stati pubblicati indicatori di compromissione.

Il punteggio basso dipende dal prerequisito: servono già privilegi amministrativi sull’host. Ma è esattamente la situazione in cui si trova un attaccante che ha già compromesso l’infrastruttura e vuole restarci senza lasciare tracce.

Chi l’ha sfruttata

La segnalazione a Broadcom è arrivata da CrowdStrike. Il 28 ottobre CrowdStrike ha pubblicato il suo 2026 Legal Threat Landscape Report, in cui attribuisce lo sfruttamento come zero-day al gruppo di matrice cinese Warp Panda, in intrusioni contro organizzazioni statunitensi tra cui studi legali.

Lo schema descritto è sempre lo stesso: accesso iniziale tramite apparati di rete esposti su Internet, movimento laterale verso vCenter, installazione di malware come BrickStorm. In diversi casi, fino all’inizio del 2026, il gruppo ha usato CVE-2026-41709 per ridurre la visibilità dell’audit trail sugli host.

In altre parole, non è la porta d’ingresso. È lo strumento per far sparire le impronte una volta dentro, ed è il motivo per cui il CVSS racconta solo una parte della storia.

Versioni affette e build corrette

Questa è la response matrix di VMSA-2026-0006.2 per CVE-2026-41709:

Prodotto	Versione	Build corretta
VCF / vSphere Foundation	9.1.x	ESXi-9.1.0.0-25370933 (già la GA 9.1)
VCF / vSphere Foundation	9.0.x	ESXi-9.0.2.0100-25595025
ESXi	8.0	ESXi80U3j-25429389
VCF	5.x	VCF 5.2.4

Le patch sono cumulative: una build successiva a quella indicata contiene già la correzione. Su 8.0, ad esempio, la 8.0 U3k (build 25595708) include sia questo fix sia quello per la VM escape CVE-2026-47876.

Attenzione a chi è su 8.0 Update 2

Ad agosto Broadcom ha rilasciato la 8.0 U2f come express patch per chi non poteva passare subito a U3. Quella patch però corregge solo CVE-2026-47876. Per CVE-2026-41709 la matrice non prevede alcuna build 8.0 U2: l’unica correzione sul ramo 8.0 è U3j o successiva.

Chi ha applicato la U2f e considera chiuso il bollettino ha quindi ancora host vulnerabili proprio alla CVE che oggi è nel catalogo KEV.

E vSphere 7.0?

La revisione .2 dell’advisory ha aggiunto indicazioni per 7.0 solo per le vulnerabilità Critical, rimandando al supporto Broadcom per chi ha un contratto di extended support. Per CVE-2026-41709, classificata Low, la matrice non riporta nulla per 7.0. Chi è ancora su questo ramo deve verificarlo direttamente con Broadcom.

Come verificare la build degli host

Per un singolo host basta il vSphere Client: selezionare l’host, scheda Summary, e leggere versione e build. In alternativa, da SSH:

esxcli system version get

L’output riporta Version, Build, Update e Patch. Su 8.0 il valore da controllare è Update: deve essere 3 con build pari o superiore a 25429389.

Perché non basta confrontare il numero di build

Sul ramo 8.0 i numeri di build non sono un indicatore affidabile tra un update e l’altro. La 8.0 U2f ha build 25626445, che è più alta della 25429389 della U3j, ma non contiene il fix per CVE-2026-41709. Uno script che controlla solo “build maggiore di” segnerebbe come sicuro un host che non lo è.

Per avere il quadro di tutti gli host da vCenter con PowerCLI, conviene quindi leggere anche il livello di update:

Connect-VIServer vcenter.dominio.local

$report = foreach ($h in Get-VMHost) {
    $v = (Get-EsxCli -VMHost $h -V2).system.version.get.Invoke()
    [pscustomobject]@{
        Host    = $h.Name
        Version = $v.Version
        Update  = $v.Update
        Patch   = $v.Patch
        Build   = $v.Build
    }
}

$report | Sort-Object Version, Update | Format-Table -AutoSize

Tutti gli host 8.0 con Update inferiore a 3, o con Update 3 ma build precedente alla 25429389, vanno aggiornati.

Aggiornamento con vSphere Lifecycle Manager

Su 8.0 il consiglio è andare direttamente all’ultima patch disponibile del ramo U3 invece di fermarsi alla U3j: le patch sono cumulative e la U3k chiude anche la VM escape CVE-2026-47876 (CVSS 9.3). Le FAQ di Broadcom su VMSA-2026-0006 vanno nella stessa direzione: l’ultima patch di 8.0 U3 contiene tutti i fix di sicurezza e di bug rilasciati.

Con un cluster gestito tramite image, la sequenza è quella abituale:

Sincronizzare il depot in vLCM. Se il sync fallisce con l’errore sul depot non accessibile, verificare la configurazione del download token (qui la guida).
Nel cluster, Updates → Image → Edit, selezionare come ESXi Version la build 8.0 U3 più recente e salvare.
Lanciare Check Compliance e poi Run Pre-check, per verificare compatibilità di driver, firmware e componenti vendor.
Remediate All: gli host entrano in maintenance mode uno alla volta, con DRS che sposta le VM.
A fine remediation, rilanciare lo script PowerCLI del paragrafo precedente per confermare livello di update e build su tutti gli host.

Prima di procedere vale sempre la regola di base: vCenter va aggiornato prima degli host. In questo caso c’è un motivo in più, perché lo stesso bollettino corregge due vulnerabilità vCenter da 9.8 sfruttabili senza autenticazione (CVE-2026-59309 e CVE-2026-59310), risolte su 8.0 dalla vCenter 8.0 U3k.

Oltre la patch: i log devono stare fuori dall’host

Un chiarimento importante: un syslog remoto non mitiga CVE-2026-41709. Se un’operazione non viene registrata, non viene nemmeno inoltrata. L’unica soluzione è la patch.

Questa vicenda però ricorda una cosa che vale in generale: se i log di un host esistono solo sull’host, chi ha i privilegi di amministratore può alterarli. Inviarli in tempo reale a un collector esterno significa che quanto viene registrato resta disponibile anche se l’host viene compromesso dopo.

Da SSH, la configurazione minima è:

esxcli system syslog config set --loghost='tcp://collector.dominio.local:514'
esxcli network firewall ruleset set --ruleset-id=syslog --enabled=true
esxcli system syslog reload

Per applicarla a tutti gli host in un colpo solo con PowerCLI:

Get-VMHost | Get-AdvancedSetting -Name Syslog.global.logHost |
    Set-AdvancedSetting -Value 'tcp://collector.dominio.local:514' -Confirm:$false

Il collector dovrebbe stare fuori dal dominio di amministrazione vSphere: un SIEM o un log server con credenziali separate, che un amministratore vCenter non possa modificare. Ricevere i log non basta: servono anche alert su eventi come l’abilitazione di SSH, l’uscita dal lockdown mode o la modifica dei permessi sugli host.

Conclusioni

CVE-2026-41709 è un buon esempio di perché il punteggio CVSS da solo non basta a decidere le priorità. Il catalogo KEV dice una cosa diversa: questa vulnerabilità è stata usata davvero, da un gruppo che punta proprio alle infrastrutture VMware.

In pratica: verificare livello di update e build di tutti gli host, portare il ramo 8.0 almeno alla U3j (meglio all’ultima U3 disponibile), non considerare chiuso il bollettino su host fermi alla U2f e, già che ci siamo, controllare che i log degli host arrivino davvero a un collector esterno.