Una campagna di attacco globale sta sfruttando attivamente CVE-2026-59310, una vulnerabilità critica (CVSS 9.8) nel server Syslog di VMware vCenter Server, per installare un accesso remoto persistente su centinaia di infrastrutture di virtualizzazione in tutto il mondo. Broadcom aveva pubblicato la patch il 29 luglio; lo sfruttamento in rete è iniziato appena cinque giorni dopo.

Cosa è successo

La falla è un directory traversal nel servizio Syslog di vCenter che consente a un attaccante con semplice accesso di rete al sistema — senza bisogno di credenziali valide — di scrivere file in posizioni non previste e ottenere l'esecuzione di codice arbitrario sul server. Insieme a CVE-2026-59310, Broadcom ha corretto lo stesso giorno anche CVE-2026-59309, una falla di bypass dell'autenticazione nello stesso componente: le due vulnerabilità, combinate, riducono drasticamente la barriera d'ingresso per chi punta a vCenter.

Un attore ritenuto riconducibile a una campagna di tipo APT ha iniziato a colpire i sistemi non aggiornati a partire dal 3 agosto. La catena d'attacco osservata dai ricercatori segue uno schema costante: sfruttamento del path traversal, seguito dalla creazione di un cron job malevolo che avvia reverse_ssh, uno strumento open source pensato per instaurare connessioni SSH in uscita verso un'infrastruttura controllata dall'attaccante. Il risultato è un accesso remoto che sopravvive ai riavvii e che, passando per una connessione in uscita anziché in entrata, elude molte configurazioni di firewall perimetrale.

Al momento della rilevazione della campagna erano già stati individuati 361 indirizzi IP vittima in 47 Paesi, con Germania, Stati Uniti, Turchia, Iran e Francia che da soli concentrano oltre la metà dei casi osservati. Per entrambe le CVE non esistono soluzioni di ripiego (workaround): l'unico rimedio è l'aggiornamento alle versioni corrette — VMware vCenter Server 8.0 U3k, VMware Cloud Foundation e vSphere Foundation 9.1.0.0300 o 9.0.2.0100.

Cosa significa per le aziende italiane

vCenter non è "un altro server da patchare": è il piano di controllo da cui si gestisce l'intera infrastruttura di virtualizzazione. Chi lo compromette non ottiene accesso a una macchina virtuale, ma alla console che le governa tutte — creazione e clonazione di VM, accesso agli snapshot, alle configurazioni di rete virtuale e, spesso, ai repository di backup collegati. È l'equivalente, nel mondo della virtualizzazione, di violare il dominio Active Directory: un solo punto di ingresso che vale quanto l'intero data center.

In Italia l'esposizione è ampia. Nonostante la migrazione verso il cloud pubblico proceda da anni, una quota rilevante di aziende medio-grandi e di enti pubblici mantiene infrastrutture VMware on-premises o in data center privati — spesso proprio a causa delle recenti revisioni di licensing di Broadcom, che hanno spinto molte organizzazioni a consolidare ambienti vSphere esistenti piuttosto che migrarli altrove nel breve termine. Il fatto che l'accesso ottenuto dagli attaccanti sia persistente e "silenzioso" (una connessione SSH in uscita, non una porta aperta in entrata) lo rende difficile da intercettare con i controlli perimetrali tradizionali, ed è precisamente il tipo di accesso che permette una permanenza prolungata nella rete prima di un'azione dirompente — furto dati, deployment di ransomware sull'intero parco VM, o entrambi.

Per i soggetti che rientrano nel perimetro NIS2 — e la gestione di infrastrutture IT è tipicamente centrale per moltissime categorie di soggetti essenziali e importanti — la segmentazione della rete di gestione (management plane) rispetto alla rete dati è una misura di sicurezza esplicitamente richiesta, non un'opzione. Un vCenter raggiungibile dalla rete utente, o peggio esposto direttamente su internet, rappresenta di per sé una carenza rilevabile in un audit. Se la compromissione porta a un'interruzione di servizio o a un'esfiltrazione di dati, per i soggetti NIS2 scatta l'obbligo di pre-notifica al CSIRT Italia entro 24 ore dalla conoscenza del fatto e di notifica completa entro 72 ore; se tra i dati transitati per le VM violate ci sono dati personali, si aggiunge la valutazione ai sensi dell'art. 33 del GDPR verso il Garante.

Cosa fare subito

  • Aggiornare immediatamente vCenter Server alla versione 8.0 U3k, o VMware Cloud Foundation/vSphere Foundation alle build 9.1.0.0300 / 9.0.2.0100: non esistono mitigazioni alternative alla patch.
  • Isolare l'interfaccia di gestione di vCenter: nessun accesso diretto da internet, accesso limitato a una rete di management dedicata e raggiungibile solo tramite VPN o jump host con MFA.
  • Cercare indicatori di compromissione: cron job non riconosciuti sull'appliance vCenter, processi o connessioni riconducibili a reverse_ssh, traffico SSH in uscita verso IP esterni non noti.
  • Verificare i log del servizio Syslog per pattern di path traversal nei giorni successivi al 3 agosto, in particolare se la patch è stata applicata dopo quella data.
  • Se si rileva una compromissione: isolare l'appliance dalla rete, ruotare tutte le credenziali amministrative di vCenter e degli host ESXi collegati, verificare l'integrità di snapshot e backup prima di qualsiasi ripristino.
  • Rivedere la superficie esposta: censire tutte le istanze vCenter presenti in azienda, comprese quelle di ambienti di test o di sedi periferiche spesso dimenticate nei piani di patching.