VMware vCenter CVE-2026-59310: 361 Server in 47 Paesi

Cinque giorni. È il tempo che un gruppo di attaccanti probabilmente legato alla Cina ha impiegato per trasformare una patch di sicurezza in un’arma. Il 29 luglio 2026 Broadcom ha pubblicato la correzione per CVE-2026-59310, una falla critica nel server Syslog di VMware vCenter con punteggio CVSS 9,8. Il 3 agosto i primi tentativi di sfruttamento erano già in corso. Il 5 agosto, 343 dei 361 server che sarebbero stati compromessi in totale risultavano già violati. Il bilancio finale, secondo l’indagine della società tedesca di incident response QUIRSO ripresa da The Hacker News, parla di 361 indirizzi IP compromessi in 47 paesi, con un ransomware derivato da Babuk usato come copertura per un’intrusione molto più profonda.

La vicenda tocca il cuore dell’infrastruttura IT di migliaia di aziende europee. VMware vCenter è il pannello di controllo che gestisce gli ambienti virtualizzati nei data center di banche, ospedali, pubbliche amministrazioni e provider cloud. Quando questo componente cade, cadono con lui centinaia di macchine virtuali. Ecco cosa sappiamo, come si è svolto l’attacco e cosa cambia per chi gestisce infrastrutture VMware in Italia.

I fatti in breve: cosa è successo con CVE-2026-59310

CVE-2026-59310 è una vulnerabilità di path traversal nel componente Syslog di VMware vCenter Server, il software di gestione centralizzata per gli ambienti vSphere. Broadcom, proprietaria di VMware dal 2023, ha reso pubblica la falla il 29 luglio 2026 assegnandole un punteggio CVSS di 9,8 su 10, la fascia più alta di gravità secondo il bollettino ufficiale di sicurezza Broadcom. Il difetto permette a un attaccante remoto e non autenticato di scrivere file al di fuori della directory riservata al servizio Syslog, ottenendo l’esecuzione di codice come utente root sull’appliance vCenter.

Non serve rubare credenziali. Non serve un accesso interno alla rete aziendale, basta che il servizio vCenter sia raggiungibile. Cinque giorni dopo la pubblicazione della patch, i ricercatori hanno osservato le prime richieste malevole contro server ancora privi dell’aggiornamento. L’analisi di Cybersecurity News ha confermato che la finestra tra disclosure e sfruttamento di massa è stata tra le più brevi registrate nel 2026 per un prodotto di virtualizzazione enterprise.

Anatomia della falla: perché il Syslog di vCenter è un bersaglio così prezioso

Il servizio Syslog di vCenter riceve e scrive log da ogni host ESXi collegato all’infrastruttura. Proprio perché deve scrivere file su disco in continuazione, un bug di path traversal in questo componente diventa una porta diretta verso l’esecuzione di codice. Gli attaccanti hanno inviato richieste appositamente costruite contenenti sequenze di traversal che sfuggono alla cartella prevista per i log, depositando un eseguibile in una posizione controllata dall’account di servizio di vCenter. Da lì, l’esecuzione del codice è praticamente immediata.

Le versioni colpite

La falla riguarda VMware Cloud Foundation, VMware Telco Cloud Infrastructure 3.0, VMware Telco Cloud Platform in tutte le release, VMware vCenter Server 8.0 (inclusi tutti gli update stream fino a 8.0 U3j) e VMware vSphere Foundation in ogni versione. Broadcom ha rilasciato le patch corrette nelle build vCenter 9.1.0.0300, vCenter 9.0.2.0100 e, per il ramo 8.0, nelle versioni 8.0 U3k oppure 8.0 U2f a seconda del branch di aggiornamento seguito dall’organizzazione.

Una seconda falla collegata: CVE-2026-59309

Nello stesso lotto di patch, Broadcom ha corretto anche CVE-2026-59309, un bypass di autenticazione usato dagli stessi attaccanti in una fase preliminare della campagna, tra il 1° e il 3 agosto, per creare un account amministrativo chiamato “vcenter_admin” e mappare l’infrastruttura vSphere tramite API REST con uno User-Agent contraffatto (“GoodMoodle-VCFleet/1.0”). Gli analisti di QUIRSO non hanno trovato sovrapposizioni dirette tra le due catene di sfruttamento sui sistemi analizzati, il che suggerisce due fasi distinte dello stesso attore.

Cronologia dell’attacco: dalla patch alla compromissione di massa

La velocità con cui la campagna è passata da zero a 361 vittime racconta molto sulla pressione a cui sono sottoposti oggi i team di patch management. La tabella qui sotto riassume la sequenza degli eventi ricostruita da The Hacker News e Tech Insider.

Data	Evento
29 luglio 2026	Broadcom pubblica le patch per CVE-2026-59310 (CVSS 9,8) e CVE-2026-59309
1-3 agosto 2026	Fase di ricognizione: creazione dell’account “vcenter_admin” tramite CVE-2026-59309
3 agosto 2026	Primi tentativi di sfruttamento di CVE-2026-59310, cinque giorni dopo la disclosure
4 agosto 2026	151 nuovi indirizzi IP compromessi in un solo giorno
5 agosto 2026	Il conteggio delle vittime raggiunge 343 IP, pari al 95% del totale finale
14 agosto 2026	Scoperto su GitHub il repository “tmpclean”, usato per cancellare le tracce dell’intrusione
17 agosto 2026	The Hacker News pubblica l’analisi completa firmata QUIRSO
18-25 agosto 2026	Il conteggio finale si assesta a 361 IP in 47 paesi, la falla entra nel catalogo KEV di CISA

La catena d’attacco passo per passo

Una volta ottenuta l’esecuzione di codice come root, gli attaccanti hanno seguito uno schema ripetibile su quasi tutte le vittime analizzate. Prima di tutto hanno scaricato un impianto malevolo, soprannominato “linuxFile” (o “systemlog”), che comunica con l’infrastruttura di comando tramite WebSocket con dati offuscati in XOR, un dettaglio insolito perché la cifratura applicativa viaggia su un trasporto ws:// non criptato a livello di trasporto.

Per mantenere l’accesso anche dopo un riavvio, il gruppo ha creato tre cronjob camuffati da processi legittimi di VMware: uno per iniettare chiavi SSH, uno per distribuire una web shell JSP chiamata “vmware-perf-update.jsp” e un terzo per rubare credenziali e creare nuovi account come “adminuser” e “vcadmin”. Un file “/etc/sudoers.d/vmware-perf” configurato ad hoc ha garantito privilegi root senza password. Per il furto di credenziali, gli script hanno interrogato la chiave di registro HKEY_THIS_MACHINE\services\vmdir e sfruttato le funzioni del modulo Python vmafd di VMware, tra cui GetMachineName, GetMachinePassword e GetDomainName, per poi muoversi lateralmente nel servizio di directory vSphere (vmdir).

Nella fase finale, gli attaccanti hanno distribuito il binario open source reverse_ssh per aprire un canale di comando persistente capace di aggirare firewall e regole NAT. Solo a quel punto, su alcune vittime, è arrivato il ransomware.

Il ransomware Babuk-derivato: obiettivo reale o cortina di fumo?

Su un sottoinsieme delle vittime, l’intrusione si è conclusa con la cifratura dei file tramite una variante derivata da Babuk, riconoscibile dall’estensione “.babyk” applicata ai file colpiti. È qui che l’analisi di QUIRSO introduce un elemento che cambia la lettura dell’intero incidente. Denis Szadkowski, ricercatore di QUIRSO, ha descritto il ransomware come possibile “cortina di fumo pensata per distrarre i difensori dall’intrusione principale e ostacolare l’analisi cifrando i file di log di ESXi”. In altre parole, il riscatto potrebbe non essere il vero obiettivo della campagna, ma un modo per far perdere tempo prezioso ai team di incident response mentre l’attore reale consolida l’accesso o esfiltra dati.

Questo tipo di ambiguità non è nuova nel cybercrime state-sponsored, dove il confine tra spionaggio e monetizzazione criminale si è fatto sempre più sottile negli ultimi due anni. Un ransomware che cifra selettivamente i log di sistema serve tanto a incassare un riscatto quanto a cancellare le prove di una permanenza più lunga nella rete.

Chi c’è dietro l’attacco: l’attore China-nexus e l’indagine QUIRSO

QUIRSO ha attribuito la campagna, con “moderata fiducia”, a un attore di lingua cinese. La valutazione si basa su una combinazione di indizi tecnici piuttosto che su una prova singola: artefatti in lingua cinese negli script creati dagli attaccanti, il riutilizzo di ricerche pubblicate da una fonte di sicurezza cinese, l’uso ripetuto di strumenti e software di gestione in lingua cinese, una vittimologia che esclude sistematicamente la Cina continentale e pattern operativi compatibili con un orario di lavoro UTC+8. Nessuna di queste caratteristiche basterebbe da sola, ma la loro convergenza ha convinto gli analisti a formulare l’attribuzione.

Un errore operativo ha aiutato i ricercatori a documentare il toolkit: un server AList mal configurato esponeva pubblicamente il listing delle directory contenenti i binari reverse_ssh usati nella campagna. Gli investigatori hanno inoltre trovato su GitHub un repository, “pikpak0066/tmpclean”, creato il 14 agosto 2026 e presentato come un semplice demone di pulizia della cartella /tmp per Linux scritto in Go. In realtà, secondo l’analisi pubblicata da The Hacker News, il tool cancella automaticamente ogni ora i file più vecchi di 24 ore, comprese le tracce dell’intrusione, e la sua ultima release includeva binari reverse_ssh aggiornati, un indizio che il repository veniva usato anche per distribuire payload.

Le vittime: dove ha colpito di più la campagna

Oltre metà dei 361 indirizzi IP compromessi si concentra in cinque paesi. La distribuzione geografica, ricostruita da Tech Insider sui dati di Check Point Research, mostra un profilo di vittime opportunistico più che mirato su un singolo settore o area geografica.

Paese	IP compromessi (stima)	Quota sul totale
Germania	55	15,2%
Stati Uniti	41	11,4%
Turchia	38	10,5%
Iran	26	7,2%
Francia	25	6,9%
Altri 42 paesi	176	48,8%

La presenza della Germania in cima alla lista, unita a quella di Francia, colloca l’Europa al centro di questa campagna, non ai margini. Per le organizzazioni italiane che dipendono da provider cloud e data center gestiti in Germania o Francia, il rischio non è teorico: un’appliance vCenter compromessa in un data center condiviso può diventare un ponte verso reti clienti multiple.

Perché vCenter è un bersaglio così critico per il mercato enterprise

VMware resta il software di virtualizzazione più diffuso nei data center enterprise europei, nonostante la migrazione di alcune aziende verso alternative come Proxmox o Nutanix dopo i rincari delle licenze imposti da Broadcom nel 2024 e 2025. Una singola appliance vCenter gestisce in media decine o centinaia di host ESXi, ciascuno con dozzine di macchine virtuali. Compromettere vCenter significa avere una visione e un controllo potenziale sull’intero cluster virtualizzato, comprese le VM che ospitano database, ERP e sistemi di posta.

Questo spiega perché un incidente di questo tipo pesa sulle assicurazioni cyber e sui costi di risposta molto più di una violazione limitata a un singolo server applicativo. Le organizzazioni colpite non devono solo bonificare vCenter, ma verificare l’integrità di ogni host ESXi collegato e ricostruire la fiducia nell’intero servizio di directory vmdir, un lavoro che richiede settimane, non giorni. Chi gestisce ambienti VMware su larga scala trova indicazioni operative utili anche nella nostra guida alla sicurezza cloud con Prowler e Trivy e nel piano di incident response in 12 step per strutturare la risposta a incidenti di questa portata.

Confronto con gli altri zero-day critici del 2026

CVE-2026-59310 non è un caso isolato. Agosto 2026 ha visto una concentrazione insolita di vulnerabilità critiche su infrastrutture di rete e virtualizzazione, tutte già sfruttate attivamente prima o subito dopo la pubblicazione della patch. Il confronto aiuta a capire quanto la finestra tra disclosure e sfruttamento si sia ristretta in tutto il settore.

Vulnerabilità	Prodotto	CVSS	Stato sfruttamento
CVE-2026-59310	VMware vCenter Server (Syslog)	9,8	361 IP in 47 paesi, ransomware Babuk-derivato
CVE-2026-68820	Windows Ancillary Function Driver (afd.sys)	7,0	Zero-day confermato, unico exploit attivo nel Patch Tuesday di agosto
CVE-2026-20349	Cisco Secure Firewall ASA/FTD (SSL VPN)	8,6	Zero-day DoS, aggiunto al catalogo KEV di CISA l’11 agosto
CVE-2026-45659	Microsoft SharePoint	Non ancora pubblicato ufficialmente	Presente nel KEV da sei settimane, oltre 200 server ancora esposti secondo Shadowserver

Il dato più preoccupante non riguarda una singola falla, ma il pattern comune: exploit pubblici entro pochi giorni dalla patch, aggiunta rapida al catalogo KEV di CISA e centinaia di sistemi che restano esposti settimane dopo l’allerta. Chi segue con regolarità le nostre analisi sui cicli di patch mensili avrà notato la stessa dinamica anche nei bollettini Microsoft di agosto.

Contesto storico: da ESXiArgs alla nuova ondata di attacchi a VMware

Non è la prima volta che l’ecosistema VMware finisce sotto attacco su scala globale. Nel febbraio 2023 la campagna ransomware ESXiArgs aveva colpito migliaia di host ESXi esposti su internet sfruttando una vulnerabilità nota da anni ma mai corretta su molti sistemi, un episodio che aveva già acceso i riflettori sulla fragilità delle infrastrutture di virtualizzazione lasciate senza patch. Da allora Broadcom ha acquisito VMware, ha rivisto il modello di licenza e ha intensificato il ritmo delle disclosure di sicurezza, ma la superficie di attacco è cresciuta insieme alla complessità dei prodotti.

La differenza tra il 2023 e oggi sta nella velocità. Con ESXiArgs erano passati mesi tra la disclosure della falla sfruttata e l’ondata di attacchi di massa. Con CVE-2026-59310 sono bastati cinque giorni per arrivare al primo attacco e meno di una settimana per compromettere il 95% delle vittime finali. Gli attaccanti oggi automatizzano la scansione delle patch appena pubblicate e trasformano un advisory di sicurezza in un piano di attacco quasi in tempo reale.

Come rilevare una compromissione: gli indicatori da cercare

Gli amministratori che gestiscono vCenter possono verificare la presenza di segnali di compromissione cercando cronjob sospetti con nomi che imitano processi legittimi di VMware, oltre a file di log anomali legati al proof-of-concept della falla. Un controllo rapido via SSH sull’appliance vCenter può partire da questi comandi.

# Verifica la presenza di cronjob sospetti che imitano servizi VMware
crontab -l -u root | grep -E "vmware-vpxd-stats-|vmware-perf-collect-|vmware-perf-sync-"

# Cerca il file di log associato al proof-of-concept della CVE-2026-59310
find / -iname "*poc59310*" 2>/dev/null

# Controlla account amministrativi creati di recente e non riconosciuti
grep -E "vcenter_admin|adminuser|vcadmin" /etc/passwd

# Verifica connessioni WebSocket in uscita non standard (possibile C2)
netstat -tupn | grep -E ":80|:8080" | grep ESTABLISHED

Nessuno di questi controlli sostituisce una verifica completa dell’integrità del sistema. Se anche un solo indicatore risulta positivo, la raccomandazione degli analisti è isolare l’appliance dalla rete, preservare le immagini disco per l’analisi forense e ricostruire vCenter da zero su una versione patchata, piuttosto che tentare una bonifica in-place.

Cosa devono fare adesso le aziende italiane ed europee

Il primo passo, ovvio ma spesso disatteso, è applicare le patch pubblicate da Broadcom il 29 luglio: vCenter 9.1.0.0300, 9.0.2.0100 oppure 8.0 U3k/8.0 U2f a seconda del ramo di aggiornamento in uso. Il secondo passo riguarda l’esposizione di rete: vCenter non dovrebbe mai essere raggiungibile direttamente da internet, e la segmentazione tra rete di gestione e rete di produzione resta la difesa più efficace contro questa classe di vulnerabilità.

Per le organizzazioni soggette alla direttiva NIS2, un incidente di questa gravità su un’infrastruttura critica rientra tra gli eventi da notificare alle autorità competenti entro le tempistiche previste dalla normativa, un tema che abbiamo approfondito nella nostra analisi sulla direttiva NIS2 in Italia. Chi gestisce ambienti Ivanti in parallelo a VMware farebbe bene a rivedere anche l’esposizione descritta nel nostro pezzo sullo zero-day Ivanti EPMM, perché la logica di attacco, bypass di autenticazione seguito da esecuzione di codice, si ripete quasi identica.

Previsioni: cosa aspettarsi nei prossimi mesi

Nuove varianti dell’exploit. Con i binari reverse_ssh già pubblici su GitHub, è probabile che gruppi ransomware indipendenti dall’attore China-nexus originale adattino la stessa catena d’attacco entro l’autunno 2026.
Pressione regolatoria su Broadcom. La rapidità di sfruttamento post-disclosure alimenterà richieste, soprattutto in ambito UE, di tempi di embargo più lunghi o di patch pre-rilasciate ai clienti enterprise prima dell’annuncio pubblico.
Aumento della domanda per il monitoraggio degli host ESXi. Le aziende di sicurezza specializzate in ambienti di virtualizzazione dovrebbero vedere una crescita della domanda di strumenti di rilevamento dedicati a vCenter e vSphere.
Nuovi casi di “ransomware come cortina di fumo”. La tecnica osservata da QUIRSO, cifrare selettivamente i log per ostacolare l’analisi forense, è probabile che venga replicata da altri attori state-sponsored nei prossimi incidenti su infrastrutture critiche.
Ulteriori dati sulle vittime italiane ed europee. Con Germania e Francia già ai vertici della lista, è plausibile che nelle prossime settimane emergano conferme di vittime anche in Italia, mano a mano che i CERT nazionali completano le notifiche.

Domande frequenti su CVE-2026-59310 e l’attacco a VMware vCenter

Cos’è esattamente CVE-2026-59310?

È una vulnerabilità di path traversal nel componente Syslog di VMware vCenter Server, con punteggio CVSS 9,8. Permette a un attaccante remoto e non autenticato di eseguire codice come root sull’appliance.

Quali versioni di vCenter sono vulnerabili?

VMware vCenter Server 8.0 (fino a 8.0 U3j incluso), VMware Cloud Foundation, VMware Telco Cloud Infrastructure 3.0, VMware Telco Cloud Platform e VMware vSphere Foundation in tutte le versioni precedenti alla patch del 29 luglio 2026.

Quali versioni risolvono il problema?

vCenter 9.1.0.0300, vCenter 9.0.2.0100 e, per il ramo 8.0, le build 8.0 U3k o 8.0 U2f a seconda dello stream di aggiornamento seguito.

Chi c’è dietro l’attacco?

QUIRSO attribuisce la campagna, con moderata fiducia, a un attore di lingua cinese basandosi su artefatti negli script, riutilizzo di ricerche pubblicate in Cina, strumenti in lingua cinese e pattern operativi compatibili con il fuso UTC+8.

Il ransomware Babuk-derivato è il vero obiettivo dell’attacco?

Secondo QUIRSO, probabilmente no. Il ricercatore Denis Szadkowski lo descrive come una possibile cortina di fumo pensata per distrarre i difensori e cancellare tracce cifrando i log di ESXi, non come l’obiettivo primario della campagna.

Quanti server sono stati compromessi?

361 indirizzi IP unici in 47 paesi, con Germania, Stati Uniti, Turchia, Iran e Francia in cima alla lista dei paesi più colpiti.

Come faccio a sapere se il mio ambiente vCenter è stato compromesso?

Verifica cronjob sospetti con nomi che imitano processi VMware legittimi, cerca file di log legati al proof-of-concept della falla e controlla la presenza di account amministrativi non riconosciuti come “vcenter_admin”, “adminuser” o “vcadmin”.

La falla è nel catalogo KEV di CISA?

Sì, CISA ha aggiunto CVE-2026-59310 al catalogo delle vulnerabilità sfruttate attivamente dopo la conferma dello sfruttamento in the wild, un pattern che ricorre spesso nelle nostre analisi del catalogo KEV di agosto 2026.

VMware vCenter Bucato: 361 Server in 47 Paesi [2026]