361 Server vCenter Colpiti Prima della Lista KEV

Nove Giorni dalla Patch a 361 Vittime

Broadcom ha pubblicato l'avviso VMSA-2026-0006 il 29 luglio 2026, rivelando CVE-2026-59310 insieme a una falla complementare di bypass dell'autenticazione, CVE-2026-59309, in VMware vCenter Server 8.0, 9.0 e 9.1. Le versioni corrette sono state rese disponibili lo stesso giorno: vCenter 9.1.0.0300, vCenter 9.0.2.0100 e vCenter 8.0 U3k o U2f, a seconda del ramo di aggiornamento in uso.

QUIRSO GmbH, società tedesca di digital forensics e incident response, afferma che l'infrastruttura controllata dall'attaccante ha registrato le prime connessioni in entrata da sistemi vCenter sfruttati il 3 agosto 2026, appena cinque giorni dopo il rilascio della patch. Entro il 7 agosto, la società aveva contato 361 indirizzi IP di vittime distinti in 47 paesi, con circa metà concentrata tra Germania, Stati Uniti, Turchia, Iran e Francia. QUIRSO ha pubblicato una regola di rilevamento YARA insieme ai risultati, ma ha trattenuto alcuni indicatori di compromissione mentre coordinava con le forze dell'ordine.

Una Funzione Syslog Che Consegna l'Intero Server

CVE-2026-59310 risiede nella logica di gestione delle directory del componente Syslog Server di vCenter. L'avviso stesso di Broadcom afferma chiaramente che un attore malevolo con accesso di rete a vCenter può sfruttare il problema per eseguire codice arbitrario, e, aspetto cruciale, senza bisogno di autenticazione preventiva. Questa combinazione, nessuna autenticazione più esecuzione di codice a livello di sistema, è ciò che ha valso alla falla il suo punteggio di gravità di 9.8 su 10 e ciò che rende ogni istanza vCenter raggiungibile da internet un bersaglio immediato, non teorico.

vCenter non è uno strumento periferico. È il piano di gestione dell'intero parco di virtualizzazione di un'organizzazione, la console che provvisiona, migra e controlla ogni macchina virtuale che un'azienda utilizza. Un avviso del fornitore per questo prodotto specifico non dovrebbe mai finire nella stessa coda di una patch applicativa di routine.

Perché reverse_ssh Batte la Regola del Firewall Che Già Avete

Invece di aprire una porta in ascolto sul server vCenter compromesso, cosa che la maggior parte del monitoraggio di rete è progettata per segnalare, gli attaccanti dietro questa campagna installano reverse_ssh, uno strumento open source in Go che fa avviare alla macchina compromessa una connessione SSH in uscita verso l'infrastruttura dell'attaccante. Poiché la connessione è in uscita, può eludere le policy di firewall e di rete configurate per bloccare il traffico in entrata non richiesto ma che lasciano passare sessioni in uscita dall'aspetto normale, dando all'attaccante un punto d'appoggio duraturo e interattivo capace di sopravvivere a una semplice verifica di segmentazione di rete.

Per un dispositivo che si trova già al centro del parco di virtualizzazione di un'organizzazione, questo meccanismo di persistenza trasforma un singolo server vCenter non patchato in una testa di ponte duratura, non in un colpo singolo.

Tesi Originale: Il Vero Nodo Qui è il Divario della KEV

La maggior parte della copertura sulle vulnerabilità misura l'urgenza in base al fatto che una falla sia finita nel catalogo Known Exploited Vulnerabilities della CISA, e molti programmi di patching sono costruiti, formalmente o informalmente, proprio attorno a quel medesimo trigger. CVE-2026-59310 smentisce questa assunzione. La telemetria indipendente sia di QUIRSO sia della società di sicurezza Rapid7 ha documentato centinaia di compromissioni reali in 47 paesi entro la prima settimana e mezza dalla divulgazione, eppure, al momento della stesura, la CVE non risultava ancora nel catalogo della CISA. Un flusso di patching che tratta l'inserimento nella KEV come il segnale per portare un avviso vCenter allo stato di emergenza era, per definizione, già settimane indietro rispetto agli attaccanti che avevano trovato e armato questa falla.

La lezione va oltre questa singola CVE. Per software di livello infrastrutturale come una console di gestione dell'hypervisor, la telemetria di una società forense indipendente o il punteggio di gravità dello stesso fornitore dovrebbero bastare da soli a far scattare il patching d'emergenza, senza attendere una voce in un catalogo governativo che, questa volta, semplicemente non è arrivata in tempo.

Cosa Devono Fare Ora gli Operatori di vCenter

Ogni organizzazione che utilizza vCenter 8.0, 9.0 o 9.1 e che non ha ancora applicato le correzioni del 29 luglio dovrebbe trattarlo come un cambiamento d'emergenza, non pianificato, e verificare anche che l'interfaccia di gestione non sia raggiungibile direttamente da internet pubblico, cosa che non dovrebbe mai accadere in primo luogo. Dato il metodo di persistenza in uscita documentato qui, monitorare le connessioni SSH in uscita avviate dai server di livello infrastrutturale, non solo l'accesso in entrata verso di essi, fa ora parte di una strategia di rilevamento completa per questa specifica campagna.

Per le entità essenziali e importanti dell'UE soggette a NIS2 che hanno gestito istanze vCenter raggiungibili da internet o comunque esposte durante la finestra di sfruttamento, questo incidente rientra esattamente nelle categorie per cui la direttiva è stata scritta: esecuzione di codice remota non autenticata su infrastruttura con sfruttamento attivo confermato e una reale prospettiva di impatto sulla riservatezza, integrità o disponibilità dell'intero parco di virtualizzazione.

Da leggere ora: Una Catena di Due Chiamate Ha Dato Root a 295 Attaccanti  |  CVSS 9.6: falla ha colpito i balancer 792 volte