La catena zero-day di Ivanti Connect Secure dà root access
zero-day di Ivanti Connect Secure sono stati usati in una catena di attacco che ha permesso a un attacker non autenticato di eseguire comandi come root, il livello di controllo più alto sul VPN appliance, secondo la società di sicurezza Volexity. Ivanti ha dichiarato il 13 ottobre di essere a conoscenza di uno sfruttamento limitato in the wild e ha detto ai clienti con versioni interessate di agire immediatamente. Per due delle falle sono disponibili fix, mentre Volexity ha detto che un fix per il terzo problema è ancora previsto in una release futura nelle prossime settimane.
Volexity ha detto di aver segnalato le falle a Ivanti dopo aver indagato su un appliance di un cliente. Quel sistema era completamente aggiornato al momento dell’attacco ed eseguiva Connect Secure versione 22.8R2.4. L’attività è iniziata il 3 ottobre ed è tracciata da Volexity come UTA0576. Ivanti Connect Secure è un VPN appliance, cioè fornisce accesso remoto alla rete di un’organizzazione, quindi una compromissione può avere conseguenze ben oltre il dispositivo stesso.
Le prime due falle sono raggruppate sotto CVE-2026-104935. Ivanti le descrive come un authentication bypass e un problema di remote code execution. In parole semplici, l’authentication bypass consente a un attacker di superare il normale requisito di login, mentre la remote code execution consente di far eseguire comandi all’appliance. Volexity ha detto che queste due falle insieme permettono l’esecuzione di codice come utente cgi-server dell’appliance. Una terza falla poi esegue la privilege escalation di quell’accesso a root, dando all’attacker il livello di controllo più potente sull’appliance.
Il record CVE depositato da Ivanti dice che Connect Secure prima della versione 25.1.3.0 è interessato. Indica la versione 22.7R2.14 o precedenti come non interessate, e indica anche le versioni 22.8R2.5, 25.1.3.0 e 25.1.3.1 come non interessate. Le release notes per 25.1.3.0 sono datate luglio 2026, quindi i clienti già su quella release sono fuori dall’intervallo interessato descritto nel record CVE. Ivanti valuta CVE-2026-104935 8,6 su 10 sulla scala di gravità CVSS, un sistema di punteggio usato per confrontare la gravità delle vulnerabilità.
La U.S. Cybersecurity and Infrastructure Security Agency, nella sua voce nel record CVE, contrassegna lo sfruttamento come attivo e l’impatto tecnico come totale. Questo è coerente con il rischio principale descritto da Volexity: un attacker non aveva bisogno di effettuare il login prima di concatenare le falle, e la catena terminava con l’esecuzione di comandi a livello root. Il report di Volexity non dice quale rischio comporti la falla di privilege escalation ancora senza fix su un appliance dove le prime due falle sono già state corrette.
Ivanti consiglia ai clienti di effettuare l’upgrade e di eseguire regolarmente il suo Integrity Checker Tool. Volexity ha detto, tuttavia, che lo strumento non ha rilevato questa specifica catena perché l’exploit ha alterato il codice della libreria solo in memoria e ha ripristinato i dati di configurazione modificati. Volexity ha anche detto che l’attacker ha adottato misure pensate per evitare il rilevamento da parte dello strumento. Di conseguenza, Volexity ha detto che confermare una compromissione richiede un’indagine forensic, inclusa network forensics e memory forensics.
I segnali riportati da Volexity provengono dal singolo incidente su cui ha indagato. Includono numeri insolitamente elevati di richieste al percorso URL /dana-na/auth/url_default/welcome.cgi, e tali richieste contenevano l’header HTTP X-DSCGI-PATH con un valore che non corrispondeva al percorso URL. Volexity ha anche indicato la directory /data/.icscap/ e l’indirizzo IP 108.165.147[.]64 come indicatori da quell’incidente. Questi dettagli dovrebbero essere trattati come indicatori di incidente, non come prova che altri attacchi apparirebbero identici.
Nel caso indagato, Volexity ha detto che l’attacker ha rubato credenziali archiviate, incluse credenziali di dominio LDAP. LDAP, o Lightweight Directory Access Protocol, è comunemente usato per cercare utenti e permessi in una directory dell’organizzazione. Volexity ha anche detto che l’attacker ha cercato password in Active Directory e ha condotto attacchi di password spraying contro account. Password spraying è quando un attacker prova password comuni su molti account invece di attaccare ripetutamente un solo account. Volexity ha detto che non è stata lasciata alcuna backdoor o web shell, e che l’attacker ha rieseguito l’intera catena di exploit per ogni comando.
Per i proprietari di siti web e i team IT, la preoccupazione pratica è che un VPN appliance spesso si trova in un punto di ingresso considerato affidabile verso i sistemi interni. Se viene compromesso, l’attacker potrebbe riuscire a raggiungere credenziali e directory services che supportano siti web, pannelli di controllo hosting, applicazioni back-office e amministrazione cloud. I report di Ivanti e Volexity non indicano un workaround temporaneo per i clienti che non possono ancora effettuare l’upgrade. Inoltre non dichiarano se l’upgrade rimuova l’accesso che un attacker potrebbe avere già ottenuto.
Volexity ha valutato con bassa confidenza che il movente di UTA0576 sia criminale piuttosto che di spionaggio. Né Ivanti né Volexity hanno detto quanti clienti siano stati attaccati. Questo lascia il record pubblico con prove chiare di sfruttamento limitato e un incidente documentato, ma senza un conteggio confermato delle vittime.
Lo stesso post di Ivanti copre anche fix per Xtraction e Neurons Patch for Intune. Ivanti ha detto di non essere a conoscenza di sfruttamento di quelle falle. I problemi includono CVE-2026-106042 in Xtraction prima della versione 2026.4 e CVE-2026-109412 in Neurons Patch for Intune, ciascuno valutato da Ivanti 9,9 su 10.
Le organizzazioni che esaminano l’esposizione da incidenti VPN e infrastrutturali possono usare AEU-I per IT, infrastruttura e consulenza security-first, che è direttamente rilevante quando i sistemi di accesso remoto fanno parte dell’ambiente. Per ora, i clienti Connect Secure interessati dovrebbero dare priorità alle indicazioni di upgrade, preservare le prove se si sospetta una compromissione, ed evitare di presumere che un integrity check pulito da solo escluda questa catena di attacco.