Le VPN aziendali Ivanti Connect Secure sono state attaccate con una catena di tre vulnerabilità che porta, senza credenziali, all’esecuzione di codice come root. La prima falla, CVE-2026-104935, è stata corretta il 13 ottobre 2026; secondo Rapid7 il 29 ottobre Ivanti ha aggiornato l’avviso e pubblicato le correzioni per le altre due, CVE-2026-111357 e CVE-2026-118527, che CISA ha inserito il 30 ottobre nel catalogo delle falle sfruttate. Chi ha installato solo le patch del 13 ottobre non è ancora protetto.
In breve
- Chi è colpito: Ivanti Connect Secure 25.1.1.2 e precedenti, 25.1.2.2 e precedenti, 22.8R2.5 e precedenti (elenco CISA aggiornato al 30 ottobre).
- Gravità: CVSS 8,6, 7,0 (8,8 per Ivanti) e 4,3; in catena danno root senza autenticazione.
- Sfruttata: sì, da inizio ottobre; Ivanti parla di sfruttamento «limitato».
- Cosa fare: passare a 25.1.1.3 (o 25.1.3.x) oppure 22.8R2.6, poi analisi forense di rete e memoria.
Le tre falle e cosa fanno
| CVE | Tipo | CVSS | Corretta in |
|---|---|---|---|
| CVE-2026-104935 | bypass dell’autenticazione per spoofing con esecuzione di comandi da remoto | 8,6 | 25.1.1.2, 25.1.3.0 / 25.1.3.1, 22.8R2.5 (13 ottobre) |
| CVE-2026-111357 | escalation a root tramite il broker dsinvoked, che si fida dei dati di configurazione DSCache | 7,0 (NVD); 8,8 (Ivanti) | 25.1.1.3, 22.8R2.6 (29 ottobre) |
| CVE-2026-118527 | nomi di file prevedibili: un utente autenticato può caricare contenuti in una posizione nota | 4,3 | 25.1.1.3, 22.8R2.6 (29 ottobre) |
La differenza di punteggio sulla 111357 dipende dalla valutazione: il record CVE considera l’attacco ad alta complessità, Ivanti a bassa complessità e con cambio di perimetro. Presi uno per uno i punteggi non sembrano drammatici; insieme, come scrive Rapid7, giustificano un intervento d’emergenza fuori dai cicli normali. NVD precisa che la 22.7R2.14 e le precedenti non sono colpite dalla 104935; secondo Rapid7, Ivanti indica come non colpite anche le appliance ISA4500, ISA6500 e ISA8500 con la 25.1.3.0 o successive.
Chi attacca e cosa cerca
Volexity attribuisce l’attività a un gruppo che chiama UTA0576 e l’ha osservata dal 3 ottobre su un’appliance con la 22.8R2.4; la società Defused, citata da BleepingComputer, fa risalire i primi segnali al 1° ottobre. Dopo l’accesso, gli attaccanti hanno cercato credenziali e segreti di Active Directory, comprese le password LAPS degli amministratori locali e le chiavi di ripristino BitLocker. Shadowserver, sempre secondo BleepingComputer, contava oltre 5.600 host Connect Secure esposti su Internet.
Attenzione: CISA avverte che l’Integrity Checker Tool di Ivanti può non rilevare lo sfruttamento, perché i comandi degli attaccanti girano in memoria. Un esito pulito non esclude la compromissione.
Cosa fare subito
- Aggiornate all’ultima build del vostro ramo: 25.1.1.3 o successiva, 25.1.3.x, oppure 22.8R2.6 se la migrazione alla 25.x non è immediata. Seguite la guida di compatibilità 25.x di Ivanti per appliance fisiche e virtuali.
- Prima di riavviare o reimpostare, conservate memoria e log dove possibile: servono per capire se c’è stata intrusione.
- Cercate gli indicatori pubblicati da Volexity e riassunti da Rapid7: richieste a
/dana-na/auth/url_default/welcome.cgicon intestazioneX-DSCGI-PATHanomala, file comeml.py,rq5.py,mk.pyospray_hits.jsonin/tmp/, segni di cancellazioni selettive nei log di audit. - Se sospettate una compromissione, seguite la procedura di ripristino indicata da CISA: backup della configurazione, ripristino di fabbrica (o ricostruzione dell’istanza virtuale), aggiornamento, ripristino della configurazione.
- Dopo il ripristino reimpostate tutte le password (dominio, amministratori, account locali), revocate e riemettete i certificati, rigenerate chiavi API e credenziali del license server. Visto l’obiettivo degli attaccanti, ruotate anche le password LAPS e le chiavi di ripristino BitLocker.
- Se usate il ramo 22.8, pianificate la migrazione: arriva a fine vita il 31 gennaio 2027.
La nostra lettura
È la terza stagione consecutiva di zero-day su Connect Secure, dopo le ondate del 2024 e del 2025. Il punto debole questa volta è il calendario: per due settimane l’unica patch disponibile chiudeva l’ingresso ma non l’escalation a root, e chi si è fermato al 13 ottobre ha un falso senso di sicurezza. Un apparato di frontiera con questo storico merita una valutazione seria sulla sua sostituzione, non solo un’altra patch. Nelle stesse settimane è stata sfruttata anche una falla dei firewall Cisco, in https://hardwarfare.it/sicurezza-informatica/vulnerabilita-patch/cisco-asa-ftd-cve-2026-76418-dos-vpn-sfruttata/; le altre allerte sono in https://hardwarfare.it/category/sicurezza-informatica/vulnerabilita-patch/.
Fonti
Immagine di copertina: Racks Amravati Data Center.jpg di PiDatacenters, licenza CC BY-SA 4.0, via Wikimedia Commons; elaborazione grafica HardWarfare.
Articolo redatto con il supporto di strumenti di intelligenza artificiale e verificato dalla redazione. Come usiamo l'AI · Come lavoriamo
