Una vulnerabilità critica di VMware vCenter, corretta da Broadcom il 29 luglio 2026, è già stata sfruttata in attacchi reali per prendere il controllo dei sistemi e distribuire malware, inclusi strumenti di accesso remoto e ransomware derivato da Babuk. Per un’azienda questo conta molto, perché vCenter è spesso il punto di gestione dell’infrastruttura virtuale: se viene compromesso, il rischio non riguarda un singolo server ma l’intero ambiente.
Le informazioni pubblicate il 17 agosto 2026 indicano che la campagna ha colpito centinaia di sistemi in decine di Paesi pochi giorni dopo la divulgazione pubblica del problema. In pratica, chi non ha ancora verificato patch, accessi amministrativi e copie di sicurezza sta lasciando aperta una porta molto appetibile agli attaccanti.
Che cosa è successo
Al centro della notizia c’è CVE-2026-59310, una falla in Broadcom VMware vCenter con punteggio CVSS 9.8, quindi classificata come estremamente grave. Secondo i ricercatori, si tratta di una vulnerabilità di directory traversal che può essere sfruttata per arrivare all’esecuzione di codice arbitrario sul server.
Broadcom ha rilasciato la correzione il 29 luglio 2026. Tuttavia, l’attività malevola osservata sarebbe iniziata appena cinque giorni dopo la divulgazione pubblica del difetto, segno di una finestra di sfruttamento molto rapida: tra annuncio tecnico, sviluppo di prove di concetto e attacchi automatizzati, il tempo utile per reagire si è ridotto a pochissimo.
La campagna è stata attribuita con confidenza moderata da QUIRSO, società tedesca di incident response, a un attore con probabile collegamento con ambienti di lingua cinese. La valutazione si basa su diversi indizi: artefatti in lingua cinese negli script, uso di strumenti e software di gestione in cinese, esclusione di bersagli nella Cina continentale e orari operativi coerenti con il fuso UTC+08:00. Non si tratta però del punto più importante per le aziende: al di là dell’attribuzione, ciò che conta è che lo sfruttamento è attivo e concreto.
Quanto è estesa la campagna
Secondo i dati riportati dai ricercatori, la campagna avrebbe compromesso 361 indirizzi IP unici in 47 Paesi. I casi osservati risultano distribuiti soprattutto in Germania (55), Stati Uniti (41), Turchia (38), Iran (26) e Francia (25).
Questi numeri non descrivono necessariamente il totale reale delle vittime, ma mostrano già due elementi essenziali:
- non si tratta di un test limitato o di un singolo caso isolato;
- il bersaglio è internazionale e trasversale, quindi nessuna organizzazione che usa vCenter dovrebbe sentirsi “fuori radar”.
Per molte PMI italiane vCenter è installato per gestire host, macchine virtuali, snapshot, reti virtuali e permessi amministrativi. In altre parole, è il cruscotto dell’infrastruttura. Se l’attaccante ottiene quel livello di accesso, può muoversi molto più rapidamente verso i sistemi critici.
Le due vulnerabilità osservate negli attacchi
La notizia non riguarda solo CVE-2026-59310. In almeno un server analizzato, QUIRSO ha osservato attività compatibili anche con CVE-2026-59309, descritta come una vulnerabilità di bypass dell’autenticazione e già oggetto di scansioni attive.
Le evidenze riportano attività malevole compatibili con lo sfruttamento di CVE-2026-59309 già dal 1° agosto 2026, seguite dalla creazione di un account amministrativo su vCenter. È un dettaglio importante: anche quando un attacco parte da una falla tecnica, spesso il passo successivo è creare persistenza tramite account, attività pianificate o servizi di sistema, così da mantenere l’accesso anche dopo un riavvio o un intervento parziale.
Nel caso di CVE-2026-59310, la catena osservata è ancora più preoccupante perché mostra un passaggio veloce da exploit a controllo operativo del sistema.
Come si muovono gli attaccanti dopo l’accesso
Secondo l’analisi pubblicata, una delle prime tracce visibili è la comparsa di un file cron anomalo chiamato “zz-poc59310-syslog.log”. Da lì, viene eseguito un comando curl o wget per scaricare una backdoor da un’infrastruttura remota, avviarla e poi cancellare il file di log usato nella fase iniziale.
I ricercatori evidenziano che la denominazione del file richiama direttamente l’identificativo della CVE e una possibile proof of concept, segno che gli attaccanti hanno trasformato rapidamente le informazioni tecniche pubbliche in una procedura di attacco pratica.
Il malware descritto come linuxFile permette l’esecuzione remota di comandi. In sostanza, il sistema compromesso apre un canale verso il server di comando e controllo, riceve istruzioni, le esegue tramite shell di sistema e restituisce il risultato all’attaccante. Il codice include anche meccanismi di riconnessione automatica e di persistenza tramite systemd e cron, cioè gli strumenti classici usati su Linux per far sopravvivere il malware ai riavvii.
La campagna fa inoltre largo uso di script e job pianificati per scaricare altri componenti, creare directory di staging, modificare permessi e avviare binari aggiuntivi. Tra questi compare anche un reverse SSH, uno strumento che consente agli attaccanti di mantenere un accesso remoto stabile verso l’ambiente compromesso aggirando molti controlli tradizionali basati sul traffico in ingresso.
Infine, la notizia cita anche il deploy di ransomware derivato da Babuk. Questo cambia completamente la priorità di risposta: non parliamo più solo di intrusione o spionaggio tecnico, ma del rischio concreto di cifratura dei sistemi, interruzione dei servizi e richiesta di riscatto.
Perché vCenter è un bersaglio così delicato
Un attacco a vCenter è diverso da un attacco a una singola postazione. Chi controlla questa piattaforma può avere visibilità e capacità operative su un insieme ampio di host e macchine virtuali. In ambienti medio-piccoli, spesso lì si concentrano:
- server applicativi;
- file server;
- gestionali e database;
- controller di dominio;
- sistemi di backup o console di gestione.
Per questo motivo la compromissione di vCenter può diventare rapidamente un moltiplicatore del danno. Anche senza entrare nei dettagli tecnici, il messaggio per un imprenditore è chiaro: se il pannello centrale della virtualizzazione viene violato, il fermo operativo può essere esteso, rapido e costoso.
Cosa significa per la tua azienda
Se in azienda, in studio professionale o in una sede secondaria usate VMware vCenter, questa notizia richiede una verifica immediata. Le priorità pratiche sono cinque.
1. Controllare subito se la patch è stata applicata
La correzione per CVE-2026-59310 è disponibile dal 29 luglio 2026. Non basta sapere che “di solito aggiorniamo”: serve una verifica puntuale della versione in uso e dello stato di aggiornamento.
2. Verificare gli accessi amministrativi e gli account creati di recente
Le evidenze pubblicate mostrano anche la creazione di account amministrativi anomali. Occorre controllare utenti, ruoli privilegiati, modifiche recenti e autenticazioni sospette. Se non avete una procedura interna, è il momento di introdurla in modo strutturato attraverso un servizio di desktop e IT management.
3. Cercare segnali di persistenza, non solo l’exploit iniziale
Anche dopo la patch, un sistema già compromesso può conservare backdoor, cron job malevoli o servizi persistenti. In altre parole, aggiornare è necessario ma non sempre sufficiente. Va eseguita una verifica degli indicatori di compromissione e delle attività pianificate.
4. Mettere al sicuro i backup e testarli davvero
La presenza di ransomware rende fondamentale avere copie di sicurezza isolate, coerenti e ripristinabili. Il vero problema non è “fare il backup”, ma essere certi di poter tornare operativi in tempi accettabili. Se i backup sono collegati allo stesso ambiente compromesso, il rischio di propagazione aumenta. Per questo conviene rivedere l’architettura con una soluzione di remote backup.
5. Trattare l’evento come un tema di continuità operativa e non solo tecnico
Se vCenter gestisce sistemi che contengono dati personali, documenti aziendali o servizi essenziali, un incidente può avere impatti anche organizzativi e normativi. In questi casi è utile coinvolgere chi presidia sicurezza, gestione infrastrutturale e adempimenti privacy, ad esempio con un supporto dedicato alla sicurezza informatica.
In sintesi: patch immediata, verifica degli accessi, ricerca di persistenza, revisione dei backup e piano di risposta. Rimandare espone a un rischio elevato perché gli attaccanti hanno già dimostrato di saper passare in pochi giorni dalla vulnerabilità pubblica all’azione sul campo.
Un segnale più ampio: il tempo tra patch e attacco si accorcia
Questa vicenda conferma una tendenza ormai evidente: il tempo che separa la pubblicazione di una falla critica dal suo sfruttamento reale continua a ridursi. Non serve aspettare settimane o mesi per vedere campagne attive. In casi come questo bastano pochi giorni.
Per le aziende ciò implica un cambio di approccio. La gestione delle patch non può più essere solo manutenzione ordinaria da fare “quando c’è tempo”. Per gli asset esposti o centrali, come le piattaforme di virtualizzazione, deve diventare un processo con priorità, responsabilità definite e verifiche periodiche.
Anche le organizzazioni più piccole, che spesso non hanno un team security interno, possono adottare misure concrete: inventario dei sistemi critici, finestre di aggiornamento concordate, controllo degli account privilegiati, log conservati e backup separati dall’ambiente principale. Sono pratiche semplici da elencare, ma decisive quando una vulnerabilità viene sfruttata in massa.
Domande frequenti
Se ho applicato la patch, sono al sicuro?
La patch è indispensabile, ma non garantisce da sola che il sistema non sia già stato compromesso prima dell’aggiornamento. Conviene controllare account amministrativi, cron job, servizi persistenti e log.
Questa minaccia riguarda solo grandi aziende?
No. vCenter è usato anche in realtà di dimensioni medie o contenute. Se il sistema è esposto o non aggiornato, la dimensione dell’azienda non è una protezione.
Il rischio vero è il furto dati o il blocco dei sistemi?
Entrambi. La campagna descritta include backdoor per il controllo remoto e componenti ransomware derivati da Babuk, quindi il pericolo può andare dalla persistenza silenziosa fino alla cifratura dei server.