Il 13 ottobre 2026 Ivanti ha reso pubblica la CVE-2026-104935, una vulnerabilità di bypass dell'autenticazione in Ivanti Connect Secure, il gateway VPN SSL molto diffuso nelle imprese e nella pubblica amministrazione. La falla è già sfruttata in attacchi reali: Ivanti parla di limited exploitation in the wild, mentre il ricercatore Defused colloca i primi tentativi al 1° ottobre e Volexity al 3 ottobre. Il dettaglio più importante, però, è un altro: la correzione rilasciata è parziale.

Cosa è successo

Secondo l'analisi di Volexity, che traccia l'attore con la sigla UTA0576 (nessuna attribuzione a un gruppo o a uno Stato noto), la CVE-2026-104935 è stata concatenata ad altre due falle: una scrittura arbitraria di file e una escalation locale dei privilegi. Il risultato è l'esecuzione di comandi come root, senza credenziali e su appliance completamente aggiornate prima del 13 ottobre. Ivanti ha corretto il bypass dell'autenticazione e la scrittura di file; la componente di escalation dei privilegi, invece, risulta ancora in lavorazione, senza una data di rilascio dichiarata.

Le versioni interessate, secondo BleepingComputer, sono Connect Secure 22.8R2.4 e precedenti, 25.1.2.2 e precedenti, 25.1.1.1 e precedenti. Un riepilogo tecnico di Decryption Digest, che cita gli advisory di Ivanti e CISA, indica come release corrette la 22.8R2.5 e la 25.1.1.2 (oppure 25.1.3.0/25.1.3.1 per il ramo 25.1.2.x) e attribuisce alla falla un CVSS 8.6. Poiché le fonti non coincidono su tutti i dettagli, prima di pianificare l'intervento conviene confermare i numeri di versione direttamente nell'advisory Ivanti. CISA ha inserito la vulnerabilità nel catalogo KEV il 13 ottobre, con scadenza di rimedio al 16 ottobre per le agenzie federali americane.

L'aspetto che rende questo caso insidioso è la tecnica. Volexity riferisce che l'attaccante non ha installato malware né web shell: ha rieseguito la catena a ogni comando, e ha manipolato i log di accesso in modo da eludere l'Integrity Checker Tool (ICT) di Ivanti. In altre parole, un controllo di integrità "pulito" non dimostra che l'appliance sia sana. L'obiettivo osservato è la raccolta di credenziali di Active Directory, il che è coerente con un VPN usato come testa di ponte verso la rete interna. Shadowserver conta oltre 5.500 istanze Connect Secure esposte su Internet, senza distinguere tra sistemi vulnerabili, già aggiornati o honeypot.

Cosa significa per le aziende italiane

Un gateway VPN è, per definizione, il punto della rete più esposto e più privilegiato: termina le sessioni degli utenti, vede le credenziali e sta dentro il perimetro. Per questo le falle di questa famiglia (Ivanti, Fortinet, NetScaler, SonicWall, che abbiamo già trattato nelle scorse settimane) sono tra le più usate per l'accesso iniziale. Nel contesto italiano pesano tre fattori.

Il primo è la diffusione nelle PMI e negli enti locali, spesso gestiti da un fornitore IT esterno: l'appliance "sta lì da anni", l'aggiornamento richiede una finestra di manutenzione e nessuno in azienda sa dire con certezza quale versione sia in produzione. Il secondo è la patch incompleta: finché l'escalation a root non è corretta, la superficie residua dipende da quanto sia raggiungibile l'interfaccia di amministrazione; ridurla è una scelta di configurazione, non di software. Il terzo è l'assenza di tracce: senza web shell né malware, l'incidente può restare invisibile per settimane, e il tempo trascorso lavora a favore di chi ha già rubato credenziali di dominio.

Il quadro normativo

Per i soggetti NIS2, la cui scadenza di aggiornamento delle informazioni verso ACN è fissata al 31 ottobre, un gateway compromesso rientra a pieno titolo nella gestione del rischio sulla catena di accesso remoto e nella gestione delle vulnerabilità: dimostrare di aver valutato e mitigato una falla sfruttata e inserita nel catalogo KEV è un elemento concreto di diligenza. Se l'analisi dei log dovesse indicare un accesso non autorizzato, scattano le valutazioni sulla notifica di incidente significativo (pre-notifica entro 24 ore dalla conoscenza, secondo l'impianto NIS2) e, se sono coinvolti dati personali, sulla notifica di violazione al Garante entro 72 ore ai sensi dell'art. 33 GDPR. Un VPN che consente di raggiungere l'Active Directory rende quasi sempre plausibile l'accesso a dati personali.

Cosa fare subito

  • Inventario: verificare se in azienda, o presso i clienti gestiti, esistono appliance Ivanti Connect Secure e quale versione eseguono.
  • Aggiornare alla release corretta indicata nell'advisory Ivanti per il proprio ramo, senza attendere la finestra ordinaria.
  • Restringere l'accesso a /dana-admin/ (interfaccia di amministrazione) ai soli IP di gestione tramite firewall, per ridurre la superficie della componente non ancora corretta.
  • Analizzare i log dal 1° ottobre: richieste POST agli endpoint di autenticazione (/dana-na/auth/login.cgi) con risposta 200 ma senza cookie di sessione DSID, interruzioni o lacune nei log di accesso, attività Kerberoasting o movimenti laterali da indirizzi del pool VPN.
  • Non fidarsi del solo Integrity Checker Tool: se i log presentano buchi o manomissioni, trattare l'appliance come compromessa; CISA indica reset di fabbrica e reinstallazione in presenza di evidenze.
  • Ruotare le credenziali degli account che transitano dal gateway, in particolare account di servizio e amministratori di dominio, e controllare gli accessi anomali ad Active Directory.
  • Monitorare il rilascio della patch per l'escalation dei privilegi e applicarla appena disponibile.

La nostra lettura

Il messaggio per chi gestisce infrastrutture è scomodo: "patchato" non significa più "sicuro", soprattutto sui dispositivi di bordo. La sequenza vista in questi mesi (nuovi zero-day su più fornitori, catene di falle, log alterati) suggerisce di trattare i gateway VPN come sistemi da cui si parte per presumere una compromissione, non come scatole da aggiornare e dimenticare. Chi può, dovrebbe abbinare l'aggiornamento a una revisione dell'esposizione: accessi amministrativi mai su Internet, autenticazione a più fattori resistente al phishing, segmentazione che impedisca a una sessione VPN di arrivare ai domain controller, e una procedura già pronta per ruotare le credenziali. Sono misure che costano meno di un incidente e che le norme sulla resilienza richiedono comunque.