CVE-2026-59310: cosa rivela la campagna contro VMware vCenter

CVE-2026-59310 non è più soltanto una vulnerabilità da correggere con la massima urgenza. La falla critica nel Syslog Server di VMware vCenter è stata resa nota e corretta da Broadcom il 29 luglio 2026, ma i ricercatori hanno osservato i primi segnali di sfruttamento già dal 3 agosto, appena cinque giorni dopo. La campagna ha raggiunto 361 indirizzi IP osservati in 47 Paesi e ha utilizzato il reverse SSH per mantenere l’accesso ai sistemi. Per Shadowserver, gli ambienti interessati devono essere considerati completamente compromessi.

Cosa permette CVE-2026-59310

Broadcom e il National Vulnerability Database (NVD), il database statunitense delle vulnerabilità informatiche, descrivono CVE-2026-59310 come una vulnerabilità di directory traversal nel Syslog Server di vCenter. Un attaccante con accesso di rete al sistema non deve autenticarsi per sfruttare la falla ed eseguire codice arbitrario sul vCenter interessato. Il punteggio CVSS è 9,8, nella fascia di gravità critica.

In termini pratici, un’appliance vCenter esposta può trasformarsi in un punto d’ingresso per stabilire la persistenza e ottenere un accesso più ampio all’infrastruttura virtuale. Alcune ricostruzioni della campagna parlano di esecuzione del codice nel contesto root dell’appliance; le descrizioni più autorevoli del fornitore e del database delle vulnerabilità confermano però soprattutto il rischio generale di esecuzione arbitraria del codice, senza documentare in modo completo i privilegi ottenuti in ogni singola intrusione.

Broadcom ha pubblicato versioni corrette, ma non ha indicato alcun workaround. L’applicazione degli aggiornamenti elencati dal fornitore è quindi la misura ufficiale di rimedio per i sistemi vulnerabili.

La cronologia: la patch prima degli attacchi

Broadcom ha divulgato CVE-2026-59310 e rilasciato le correzioni il 29 luglio. QUIRSO ha segnalato indizi di sfruttamento attivo a partire dal 3 agosto, con una rapida espansione della campagna nei giorni successivi.

La sequenza è importante per la risposta agli incidenti. Un sistema aggiornato dopo il 3 agosto non può essere considerato pulito solo perché l’installazione della patch è andata a buon fine. Gli amministratori devono separare due attività: correggere la vulnerabilità e verificare l’eventuale compromissione. Prima si applica l’aggiornamento; poi si controlla se l’attaccante aveva già ottenuto e mantenuto l’accesso.

L’ampiezza della campagna

I ricercatori hanno associato l’attività a 361 indirizzi IP vittima osservati in 47 Paesi. Germania, Stati Uniti, Turchia, Iran e Francia rappresenterebbero oltre la metà dell’insieme rilevato.

Il dato va interpretato con cautela: un indirizzo IP non corrisponde necessariamente a una singola organizzazione. Parlare di “361 vittime” non dimostra quindi che siano state colpite 361 aziende o istituzioni diverse. Le informazioni disponibili indicano comunque una campagna estesa contro sistemi vCenter accessibili da Internet o esposti sulla rete.

Perché si parla di un possibile legame con la Cina

QUIRSO ha valutato con moderata fiducia un possibile collegamento con la Cina. Tra gli elementi citati figurano artefatti in lingua cinese, strumenti e ricerche già riutilizzati pubblicamente, attività compatibili con gli orari lavorativi UTC+08:00 e un insieme di vittime che sembrava escludere la Cina continentale.

Questi indizi possono sostenere una valutazione di tipo regionale o linguistico, ma non identificano uno specifico gruppo statale cinese né dimostrano una direzione governativa. L’attribuzione basata su malware, fasce orarie e modalità di selezione delle vittime può cambiare quando emergono nuove prove. La descrizione più prudente è quindi “attore sospettato di avere un legame con la Cina”, non operazione statale confermata.

La catena d’intrusione ricostruita

Secondo le ricostruzioni disponibili, gli attaccanti avrebbero utilizzato CVE-2026-59310 per l’esecuzione iniziale, installando poi più livelli di persistenza e accesso:

1. Directory traversal: richieste appositamente costruite al servizio Syslog permettevano di uscire dal percorso previsto e scrivere contenuti controllati dall’attaccante.
2. Persistenza tramite cron: gli aggressori avrebbero creato voci cron malformate, così da eseguire comandi successivi tramite attività pianificate.
3. Distribuzione della backdoor: secondo i report sulle intrusioni osservate, curl o wget scaricavano una backdoor denominata linuxFile, offuscata con WebSocket e XOR.
4. Reverse SSH: gli attaccanti installavano strumenti reverse SSH per creare connessioni in uscita verso infrastrutture sotto il loro controllo. Shadowserver ha riferito che questo meccanismo di persistenza era presente su tutte le vittime incluse nel suo rapporto speciale.
5. Abuso di account e credenziali: gli investigatori hanno segnalato account amministrativi vCenter ed ESXi non autorizzati e l’uso improprio di credenziali del VMware Directory Service.
6. Distribuzione del ransomware: almeno alcune ricostruzioni collegano l’attività a una variante di ransomware derivata da Babuk, che aggiunge l’estensione .babyk.

Il dato sul reverse SSH è particolarmente rilevante. La conclusione operativa di Shadowserver è che i sistemi sui quali è stato installato questo meccanismo debbano essere trattati come completamente compromessi. Eliminare un binario o cancellare un processo cron, senza ricostruire la fiducia nell’appliance e ruotare le credenziali privilegiate, non è una strategia di ripristino sufficiente.

Il ransomware potrebbe essere servito anche a nascondere le tracce

L’attività associata all’estensione .babyk non descrive necessariamente una campagna ransomware convenzionale, orientata soprattutto alla cifratura indiscriminata e all’estorsione. Gli analisti hanno ipotizzato che la cifratura selettiva dei log ESXi potesse avere lo scopo di ostacolare le indagini e nascondere le prove.

Si tratta però di un’inferenza, non di una conferma dell’intento degli attaccanti. I responsabili della sicurezza dovrebbero esaminare entrambe le possibilità: l’impatto del ransomware sulle macchine virtuali e la manipolazione deliberata dei log per rendere più difficile ricostruire l’intrusione.

Il repository GitHub usato per mascherare gli strumenti

Le ricostruzioni hanno inoltre collegato l’operazione a un repository GitHub che presentava binari reverse SSH come un’utilità Linux per la pulizia dei file temporanei. Mascherare uno strumento di persistenza da programma amministrativo o di manutenzione può facilitarne la distribuzione e renderlo meno evidente durante i controlli ordinari. Le prove disponibili non stabiliscono però in modo indipendente chi gestisse il repository: la sua esistenza non può quindi essere considerata una prova di attribuzione.

L’effetto su Broadcom e sul business VMware

Il 14 agosto le azioni Broadcom sono scese di circa il 5-6%, mentre gli investitori reagivano alle notizie sullo sfruttamento attivo della vulnerabilità VMware. Una ricostruzione ha indicato un passaggio da 417,82 a 392,99 dollari nella stessa seduta.

I report sulla sicurezza sono stati uno dei fattori del calo, ma non necessariamente l’unico. La copertura di mercato contemporanea ha citato anche preoccupazioni più ampie, tra cui l’esposizione al debito legato all’intelligenza artificiale. Non è quindi corretto attribuire interamente a CVE-2026-59310 la variazione del titolo o una precisa quantità di capitalizzazione persa.

Le informazioni disponibili non bastano neppure per concludere che la campagna abbia già provocato una riduzione misurabile dei ricavi VMware. Gli effetti aziendali più plausibili nel breve periodo sono i costi di remediation per i clienti, il rischio di interruzioni operative e la pressione reputazionale. Eventuali conseguenze durature sui ricavi richiederebbero comunicazioni della società o ulteriori dati finanziari.

Cosa devono fare gli amministratori di vCenter

Applicare la patch è il primo passo, non l’ultimo. Le organizzazioni dovrebbero:

1. Installare immediatamente le versioni corrette di Broadcom su ogni istanza vCenter interessata, dando priorità ai sistemi esposti a Internet e alle appliance raggiungibili da ampie porzioni della rete interna. Broadcom non indica alcun workaround.
2. Considerare compromessi i sistemi con indicatori sospetti, tra cui modifiche inattese a cron, artefatti reverse SSH, linuxFile, download non spiegati tramite curl o wget, account vCenter o ESXi sconosciuti e attività anomala del VMware Directory Service.
3. Isolare le appliance sospette e, quando possibile senza compromettere le esigenze operative, conservare immagini dei dischi, log e dati volatili prima del ripristino.
4. Ruotare tutte le credenziali privilegiate, comprese quelle di vCenter SSO, VMware Directory Service, ESXi o root, API, account di servizio e amministratori collegati. Occorre inoltre invalidare le sessioni attive e verificare i percorsi di federazione.
5. Ricostruire i sistemi invece di limitarsi a “ripulirli” quando è stata confermata la persistenza. Account non autorizzati, processi cron, binari, chiavi SSH e tunnel vanno rimossi nell’ambito di un processo documentato di risposta agli incidenti.
6. Cercare segnali nell’intera infrastruttura virtuale, inclusi attività .babyk, connessioni SSH o WebSocket in uscita inattese, account abusivi e tracce di manomissione dei log ESXi.
7. Ripristinare dati e telemetria affidabili da backup immutabili e verificati quando log o configurazioni sono stati alterati.
8. Ridurre l’esposizione futura limitando l’accesso amministrativo a vCenter a reti di gestione segmentate e monitorando le connessioni in uscita da vCenter ed ESXi.

La conclusione operativa è semplice: aggiornare ogni sistema vCenter vulnerabile, ma non confondere una patch installata correttamente con un ambiente integro. La combinazione di sfruttamento rapido, reverse SSH persistente e abuso delle credenziali impone di trattare le appliance esposte come potenziali compromissioni complete.