VMware vCenter CVE-2026-59310: patch il 29 luglio, violato il 3 agosto

Broadcom ha rilasciato la patch il 29 luglio. Le prime appliance vCenter compromesse hanno iniziato a contattare l'infrastruttura degli attaccanti il 3 agosto. Cinque giorni tra la divulgazione e lo sfruttamento di massa della macchina che controlla l'intero patrimonio virtuale — e al 7 agosto i ricercatori contavano 361 vittime distinte in 47 Paesi. Se il vostro vCenter era raggiungibile da Internet e stavate ancora pianificando la finestra di manutenzione, un operatore di livello APT era già dentro.

CVE-2026-59310 è un directory traversal non autenticato nel servizio Syslog di vCenter, valutato CVSS 9.8, che un attaccante remoto con accesso di rete può trasformare in lettura/scrittura arbitraria di file e, infine, esecuzione di codice sull'appliance. Broadcom lo ha divulgato nell'advisory VMSA-2026-0006 il 29 luglio 2026 senza alcun workaround: la patch è stata l'unica risposta supportata fin dal primo giorno. Questo è il resoconto di cosa sia, di come si sia svolta la campagna e del runbook di remediation che la maggior parte delle analisi tralascia.

Perché un bug Syslog su vCenter è un evento a livello di datacenter

vCenter non è una console di gestione qualsiasi. È l'unico piano di controllo di vSphere: ogni host ESXi, ogni datastore, ogni VM, ogni snapshot, e le credenziali vpxuser che gli permettono di impartire comandi agli host. L'esecuzione di codice su vCenter non è un punto d'appoggio su un singolo server — è controllo amministrativo sull'intera infrastruttura virtualizzata sottostante. È esattamente per questo che i gruppi ransomware e gli attori statali trattano da tre anni la gestione VMware come bersaglio prioritario: l'esecuzione su vCenter consente di cifrare in massa i VMDK a livello di hypervisor, sotto il sistema operativo guest dove risiede la maggior parte degli EDR.

Il servizio Syslog peggiora le cose. Gli endpoint di logging sono il tipo di superficie che gli amministratori espongono senza pensarci — "sono solo log" — e per definizione elaborano input influenzato dall'attaccante. Un directory traversal in quel punto significa che una parte remota può uscire dalla directory prevista con sequenze ../ e raggiungere file che il servizio non avrebbe mai dovuto toccare: scrivere un payload in una posizione che l'appliance eseguirà in seguito, o leggere segreti direttamente dal disco. Nessuna credenziale, nessuna interazione dell'utente: l'accesso di rete è l'unico prerequisito.

Dentro CVE-2026-59310: dal path traversal all'RCE non autenticato

Il meccanismo è un classico che continua a funzionare perché la normalizzazione dell'input è genuinamente difficile da gestire correttamente su un percorso di logging. Il gestore Syslog accetta un parametro simile a un percorso e non lo canonicalizza prima dell'uso. Gli si fornisce una sequenza di traversal e la scrittura finisce fuori dalla sandbox; si concatena la scrittura arbitraria a una posizione che l'appliance carica — una directory cron, uno script che il servizio include, una configurazione che il sistema rilegge — e la scrittura di file diventa esecuzione di comandi. L'advisory Broadcom conferma la catena di impatto: attaccante di rete non autenticato, esecuzione di codice arbitrario, severità massima.

VMSA-2026-0006 raggruppa più di un problema. I ricercatori hanno osservato anche scansioni contro una vulnerabilità gemella di bypass dell'autenticazione (CVE-2026-59309, anch'essa valutata 9.8) coperta dallo stesso advisory — un promemoria che "abbiamo applicato la patch per l'RCE" non equivale a "abbiamo applicato l'advisory". Trattate il VMSA come un'unica unità di lavoro, non come un singolo CVE.

La finestra di cinque giorni: come si è svolta la campagna

La curva di sfruttamento è la parte che ogni consiglio di amministrazione dovrebbe vedere, perché demolisce la difesa del "applichiamo le patch con cadenza mensile". Secondo il resoconto di BleepingComputer sulla telemetria di QUIRSO:

Data	Evento
29 lug	Broadcom divulga VMSA-2026-0006 e rilascia le patch
3 ago	Le prime appliance compromesse contattano l'infrastruttura dell'attaccante
4 ago	151 IP vittima osservati
5 ago	343 IP vittima
7 ago	361 IP vittima in 47 Paesi

Più della metà delle vittime si trovava in Germania, Stati Uniti, Turchia, Iran e Francia. L'attività è compatibile con una sospetta minaccia persistente avanzata più che con criminalità di massa — deliberata, silenziosa, orientata alla persistenza. Come ha osservato Dark Reading, sembrava una campagna globale coordinata, non scansione opportunistica.

La scelta post-exploitation è ciò che rende notevole questa campagna. Invece di lasciare una web shell rumorosa, gli operatori hanno usato reverse_ssh — uno strumento open source legittimo che stabilisce una sessione SSH in uscita dalla vittima verso l'infrastruttura controllata dall'attaccante. Poiché la connessione parte dall'interno, attraversa indenne le regole del firewall in uscita che bloccano l'SSH in ingresso, e si nasconde dentro un protocollo che ogni amministratore si aspetta di vedere. La persistenza è stata fissata con un cron job malevolo, così il tunnel sopravvive al riavvio.

"Abbiamo applicato la patch a vCenter entro l'SLA." "Quale SLA — quello dei 30 giorni? L'exploit era attivo dal quinto giorno. Quando è stata l'ultima volta che l'appliance ha aperto una connessione SSH in uscita che non avevate schedulato voi?"

È la seconda domanda quella che conta, e quasi nessuno sa rispondere a memoria. La patch chiude la porta. Non fa nulla contro l'operatore entrato tra il 3 agosto e il momento in cui avete applicato la patch.

reverse_ssh: il problema della persistenza silenziosa

reverse_ssh è popolare tanto tra i red team quanto tra gli attaccanti proprio perché è insignificante sul filo. È SSH — cifrato, atteso, e spesso non registrato a livello di payload. NDR ed EDR basati su firme che si agganciano a binari noti-malevoli faticano qui: lo strumento è open source, ricompilabile con banalità, e il suo traffico è indistinguibile da qualunque altra sessione SSH incapsulata in TLS con la sola ispezione del contenuto. QUIRSO ha pubblicato una regola YARA per il binario client, utile sull'host — ma solo se il binario è ancora su disco e il nome del file non è stato cambiato.

Ciò che invece lo tradisce è il comportamento: un'appliance vCenter che storicamente riceve solo connessioni di gestione che improvvisamente origina una sessione in uscita sostenuta verso un ASN mai visto prima, a orari strani, su un host che non ha alcuna ragione di parlare SSH verso l'esterno. È un'anomalia nella forma del traffico, non una firma — ed è esattamente la classe di evento che l'ispezione cieca al contenuto manca e che l'analisi comportamentale cattura.

Remediation

Un runbook completo e difensivo per CVE-2026-59310. Verificate ogni stringa di versione contro VMSA-2026-0006 prima di agire.

1. Sono vulnerabile? Controllate la build di vCenter in esecuzione:

vmware-appliance version      # oppure: UI di vCenter → Administration → Deployment

Qualsiasi vCenter Server 9.1 sotto 9.1.0.0300, 9.0 sotto 9.0.2.0100, o 8.0 sotto 8.0 U3k (dipende dal branch — alcune linee 8.0 risolvono in U2f) è vulnerabile. Se il servizio Syslog è abilitato e l'appliance è raggiungibile da una rete non attendibile, consideratela un bersaglio attivo.

2. Patch — versioni corrette esatte (da VMSA-2026-0006):

• vCenter Server 9.1 → 9.1.0.0300
• vCenter Server 9.0 → 9.0.2.0100
• vCenter Server 8.0 → 8.0 U3k (oppure 8.0 U2f su quel branch)

Non esiste alcun workaround. La patch è l'unica correzione supportata dal vendor.

3. Non potete applicare la patch subito? Controlli compensativi.

• Limitate l'accesso di rete alle interfacce di gestione di vCenter a un solo jump host / VLAN di management indurita. vCenter non dovrebbe mai essere raggiungibile da Internet.
• Bloccate le connessioni in uscita dall'appliance vCenter tranne verso destinazioni note e necessarie (host vSphere, server di aggiornamento). Questo interrompe direttamente il percorso di egress di reverse_ssh.
• Aggiungete alert di egress per qualsiasi SSH in uscita originato da appliance vCenter.

4. Cercate segni di compromissione. Presumete l'esposizione se la macchina era raggiungibile prima della patch.

• Persistenza (MITRE T1053.003 — Scheduled Task/Job: Cron): enumerate cron per voci che non avete creato.

  ls -la /etc/cron.d/ /etc/cron.*/ ; crontab -l ; cat /var/spool/cron/crontabs/* 2>/dev/null
  

• Tunnel C2 (MITRE T1572 — Protocol Tunneling): cercate SSH in uscita originato dall'appliance.

  ps aux | grep -i ssh | grep -v sshd
  netstat -antp | grep ESTABLISHED    # SSH in uscita verso IP non familiari
  

• Strumenti rilasciati: cercate nei percorsi scrivibili da chiunque il binario reverse_ssh (il nome può essere cambiato):

  find /tmp /var/tmp /dev/shm -type f -newermt "2026-07-29" 2>/dev/null
  

• Accesso iniziale (MITRE T1190 — Exploit Public-Facing Application): rivedete i log del servizio Syslog e dell'appliance in cerca di artefatti di path traversal (sequenze ../, scritture su percorsi inattesi) attorno e dopo il 29 luglio.
• Applicate la regola YARA pubblicata da QUIRSO per i binari client reverse_ssh su tutto il parco — ma non considerate una scansione YARA pulita come prova di sicurezza; il binario potrebbe essere sparito o rinominato.

5. Eradicate + verificate. L'ordine conta: eradicate, poi patchate, poi confermate la pulizia.

• Isolate dalla rete qualsiasi appliance con compromissione confermata prima di toccarla.
• Rimuovete le voci cron malevole e i binari rilasciati.
• Ruotate tutto ciò che l'appliance poteva raggiungere: credenziali dell'amministratore SSO di vCenter, service account, token API, e il trust vpxuser verso gli host ESXi. Presumete il furto di credenziali (T1078 — Valid Accounts); una macchina patchata con credenziali rubate è comunque compromessa.
• Applicate la patch alla versione corretta.
• Verificate: confermate che la build in esecuzione corrisponda alla versione corretta, poi monitorate per 24–48 ore qualsiasi connessione in uscita o esecuzione cron anomala prima di dichiarare pulita l'appliance.

Validate la correzione prima che lo faccia il prossimo APT

La lezione scomoda di CVE-2026-59310 non è che mancasse una patch — c'era, dal primo giorno. È che il divario tra "patch disponibile" e "patch applicata e verificata pulita" è dove è vissuta l'intera campagna, e la maggior parte delle organizzazioni non riesce nemmeno a elencare quali delle proprie appliance vCenter fossero esposte durante quel divario, tantomeno a dimostrare che la correzione tenga.

È la domanda operativa a cui è costruito per rispondere il pilastro AI Generative Pentest di Zero Hunt. Le sue campagne attivate dal cambiamento lanciano una valutazione completa entro un'ora quando arriva un nuovo advisory o compare un nuovo asset sul perimetro — così un RCE su vCenter appena divulgato viene validato contro il vostro patrimonio immediatamente, non al prossimo test trimestrale. Lo swarm a 10 agenti scrive una catena di exploit per singolo bersaglio con un modello locale invece di rieseguire un PoC pubblico, così dimostra se questa appliance è davvero raggiungibile e sfruttabile — trasformando un titolo CVSS 9.8 in un finding confermato e firmato ECDSA che potete prioritizzare, ogni exploit eseguito dentro un container effimero indurito che non tocca mai l'host. Contro una catena traversal-to-RCE come questa, è la differenza tra "pensiamo di aver patchato tutto" e "l'abbiamo dimostrato, ed ecco la prova".

La metà reverse_ssh dell'attacco è dove il secondo pilastro guadagna il suo posto. L'AI Traffic Analysis di Zero Hunt esegue un modello di deep learning proprietario con quattro teste di inferenza — traffico sospetto, classificazione malware, identificazione del tipo di attacco, fingerprinting delle applicazioni — localmente sulla GPU dell'appliance a oltre 2,7 Gbit/s. Una sessione SSH in uscita da una macchina vCenter che ha sempre e solo ricevuto traffico di gestione, diretta a un ASN mai contattato, è precisamente l'anomalia comportamentale che l'ispezione del contenuto manca e che questo modello fa emergere mentre il tunnel è attivo — non nel digest SIEM di domani mattina, quando ormai l'operatore si è già mosso lateralmente attraverso l'infrastruttura che il vostro vCenter controlla.