VMware non aggiornato: quando una vulnerabilità diventa un attacco ransomware

Per molti team IT, il ransomware non è più una possibilità lontana. È una realtà operativa che può interrompere il business nel giro di poche ore, non settimane. Questo rischio diventa ancora più immediato quando l’infrastruttura su cui girano i carichi di lavoro principali dipende da versioni software obsolete, esposte o difficili da mantenere completamente aggiornate.

È proprio per questo che gli ultimi avvisi relativi allo sfruttamento di vulnerabilità VMware sono così importanti. Nel febbraio 2026, BleepingComputer ha riportato che la CISA aveva confermato che gruppi ransomware stavano sfruttando una vulnerabilità di sandbox escape ad alta gravità in VMware ESXi, CVE-2025-22225, precedentemente utilizzata in attacchi zero-day. La falla era stata corretta da Broadcom nel marzo 2025, ma l’incidente ha evidenziato una dura realtà sul campo: quando le organizzazioni continuano a utilizzare infrastrutture obsolete o non più supportate, il divario tra la pubblicazione di una patch e il rischio reale può diventare pericolosamente ampio.

Questo problema emerge in un momento in cui molte organizzazioni stanno già affrontando sfide che vanno oltre la semplice gestione delle vulnerabilità. Devono anche gestire scadenze di fine ciclo di vita dei prodotti, cambiamenti nelle politiche di supporto, pressioni di budget e la complessità operativa di mantenere sicuri ambienti di virtualizzazione legacy senza interrompere il business.

Il problema delle policy: quando le patch non sono più un’opzione

Per molte organizzazioni, l’ostacolo all’installazione delle patch non riguarda più solo i tempi di fermo o il carico operativo. Riguarda la conformità delle licenze.

Dopo l’acquisizione di VMware da parte di Broadcom, il panorama del supporto per le licenze perpetue (buyout) è cambiato radicalmente. Il problema principale è che, se la versione VMware in uso è fuori dalla finestra di supporto e non si è passati a un modello in abbonamento, non è più possibile ricevere ufficialmente le patch, né dal punto di vista legale né tecnico.

Consideriamo la situazione che molti clienti stanno affrontando oggi:

• Utenti vSphere 7.x: il supporto generale è terminato nell’ottobre 2025. Ora si trovano nella fase di “technical guidance” (fino a ottobre 2027), che non prevede nuove patch di sicurezza.
• vSphere 6.x e precedenti: queste versioni hanno superato da tempo la data di End of General Support (EoGS).
• Clienti con contratti di manutenzione scaduti: anche su versioni supportate come vSphere 8.x, se il contratto di manutenzione è scaduto non è più possibile ricevere aggiornamenti. Come dimostrato da casi mediatici come quello del retailer Tesco, ai clienti viene comunicato che non possono installare aggiornamenti se non passano a un modello di abbonamento.

Questo crea un paradosso preoccupante: i sistemi più vulnerabili sono proprio quelli bloccati su versioni non supportate, per le quali non esisteranno più patch.

Gli attaccanti lo sanno. Eseguono scansioni alla ricerca di sistemi che eseguono queste versioni obsolete e non aggiornabili, sapendo che vulnerabilità come CVE-2021-21974 (e altre simili) rappresentano una porta aperta permanente.

Anatomia di un attacco su un sistema non aggiornato

L’attacco ransomware ESXiArgs è un esempio da manuale di exploit “low and slow” che diventa devastante quando non viene risolto. Come mostra la nostra analisi, l’attacco si sviluppa in fasi chiare una volta ottenuto il primo accesso tramite CVE-2021-21974:

1. Accesso iniziale (CVE-2021-21974): l’attaccante sfrutta un heap overflow nel servizio OpenSLP tramite la porta UDP 427 per ottenere remote code execution.
2. Deployment: file malevoli (encrypt, encrypt.sh, public.pem) vengono caricati nella directory /tmp/.
3. Ricognizione e cifratura: il ransomware enumera tutti i volumi di storage, prendendo di mira file critici delle macchine virtuali come: .vmdk (dischi virtuali), .vmx (configurazione VM), .vswp (file di swap). Utilizza una combinazione dell’algoritmo Sosemanuk e della crittografia RSA per bloccare i file.
4. Elusione delle difese: per impedire il ripristino, elimina log di sistema, attività pianificate e file di backup.
5. Nota di riscatto: lascia il file “How to Restore Your Files.html”, richiedendo il pagamento.

Per le organizzazioni che utilizzano versioni VMware non supportate, i suggerimenti tipici delle advisory di sicurezza, come l’aggiornamento a una versione corretta, semplicemente non sono applicabili. Restano solo due opzioni: pagare il riscatto (scelta mai raccomandata) o perdere i dati.

Costruire un futuro resiliente: sicurezza oltre il ciclo delle patch

Questo incidente evidenzia un cambiamento cruciale nella strategia IT: non è più possibile permettersi di gestire infrastrutture che non possono ricevere aggiornamenti di sicurezza.

Affidarsi esclusivamente al ciclo di patch del vendor, soprattutto quando è legato a modelli di abbonamento con condizioni di licensing rigide, crea un singolo punto di fallimento per l’intera postura di sicurezza.

Per i clienti dei nostri partner, e per qualsiasi organizzazione che affronta questa sfida, è il momento di considerare alternative che integrino la sicurezza fin dalle fondamenta, invece di trattarla come un componente opzionale.

La Sangfor Virtualization offre un percorso concreto in questa direzione. Basato sul principio dell’integrazione della sicurezza, l’hypervisor di Sangfor non è solo una piattaforma per eseguire macchine virtuali, ma una soluzione completa di data center con la sicurezza al centro.

Ecco come Sangfor affronta alla radice il problema evidenziato da ESXiArgs:

• Sicurezza e infrastruttura unificate: a differenza del modello frammentato di hypervisor di terze parti che richiedono strumenti di sicurezza separati, Sangfor HCI integra nativamente funzionalità di anti-ransomware, next-generation firewall e micro-segmentazione. Questo approccio “built-in, not bolted-on” significa che le policy di sicurezza fanno parte dell’infrastruttura stessa.
• Rilevamento proattivo delle minacce: la piattaforma utilizza IA e analisi comportamentale per rilevare attività tipiche del ransomware, come cifrature massive o cancellazione dei backup, in tempo reale, fermando gli attacchi prima che causino danni.
• Eliminazione della dipendenza dal ciclo di patch: con Sangfor non si dipende dalle policy di patch di un vendor terzo per l’hypervisor principale. Gli aggiornamenti di sicurezza fanno parte di uno stack software unificato e gestibile, che mantiene l’infrastruttura resiliente senza ostacoli complessi legati alle licenze.
• Operazioni semplificate: la migrazione da ambienti VMware legacy a Sangfor HCI semplifica il data center: riduzione della complessità delle licenze, diminuzione del TCO e gestione centralizzata di compute e sicurezza da un’unica console.
• Tecnologia e servizi integrati: è possibile sfruttare l’expertise di sicurezza dei servizi MDR per monitorare l’infrastruttura virtuale alla ricerca di attività ransomware. I sensori di endpoint e rete si integrano nativamente con HCI e forniscono ai servizi MDR la visibilità necessaria per rilevare e rispondere agli incidenti di sicurezza. Questo trasforma la soluzione da semplice piattaforma di virtualizzazione a un’esperienza completa di computing sicuro.

Cosa puoi fare ora?

Conclusione

ESXiArgs non è solo l’ennesima campagna ransomware: è il sintomo di un modello operativo ormai rotto. Le organizzazioni che continuano a utilizzare sistemi legacy non supportati e “non aggiornabili” non stanno semplicemente accettando un rischio, stanno invitando il disastro.

Passando a una piattaforma come Sangfor Virtualization, dove la sicurezza è un componente integrato e costantemente aggiornato dell’infrastruttura, è finalmente possibile rompere il ciclo di vulnerabilità ed esposizione dovuto a licenze non aggiornate.

Non aspettare che il prossimo attacco inevitabile su una vecchia vulnerabilità ti costringa ad agire.