Ivanti Connect Secure, due falle sfruttate: le versioni da aggiornare

Due vulnerabilità di Ivanti Connect Secure, CVE-2026-111357 e CVE-2026-118527, sono state aggiunte il 30 ottobre 2026 al catalogo KEV di CISA, che raccoglie le falle per cui esistono prove di sfruttamento. Ivanti aveva pubblicato le correzioni il giorno prima: per risolvere entrambi i difetti servono le versioni 25.1.1.3 o 22.8R2.6. Le versioni 25.1.1.2 e 22.8R2.5, distribuite a ottobre per un’altra vulnerabilità, non bastano, secondo l’analisi di Rapid7 sull’avviso aggiornato.

Per chi gestisce questi apparati di accesso remoto, aggiornare resta necessario ma non dimostra che il dispositivo non sia stato compromesso prima dell’installazione della patch. Nel caso esaminato da Volexity, l’attaccante ha ottenuto privilegi di root e ha cercato credenziali e informazioni di Active Directory. La ricostruzione riguarda un apparato investigato e non prova che ogni installazione vulnerabile sia stata attaccata.

Come si combinano le due vulnerabilità

I due difetti hanno funzioni diverse. Rapid7 descrive CVE-2026-111357 come una vulnerabilità che consente a un attaccante locale autenticato di elevare i privilegi. CVE-2026-118527 riguarda invece la generazione di identificativi prevedibili e, secondo la voce CISA citata da Rapid7, può permettere a un attaccante remoto autenticato di caricare contenuti in una posizione nota sul disco.

Secondo Ivanti, riferisce Rapid7, entrambe le vulnerabilità sono state sfruttate insieme a CVE-2026-104935, una falla di aggiramento dell’autenticazione corretta con aggiornamenti precedenti. La catena mostra perché una patch può non bastare se altre vulnerabilità restano aperte: aver installato l’aggiornamento di metà ottobre per CVE-2026-104935 non equivale ad aver corretto i due difetti aggiunti al KEV a fine mese.

La ricostruzione pubblicata da Volexity sull’apparato indagato descrive una catena che ha consentito all’attore tracciato come UTA0576 di ottenere accesso con privilegi di root. L’indagine riferisce che sono state cercate credenziali memorizzate sull’apparato e informazioni di Active Directory, incluse password LAPS e chiavi di ripristino BitLocker. Volexity descrive l’aggiramento dell’autenticazione e l’escalation dei privilegi; l’attribuzione di CVE-2026-118527 come ulteriore componente della catena compare nell’avviso aggiornato di Ivanti, come riportato da Rapid7. Il rapporto di Volexity è del 13 ottobre, quindi precede l’aggiornamento del 29 ottobre.

Quali versioni correggono entrambi i difetti

Secondo la tabella di Rapid7, le versioni 25.1.1.2 e 22.8R2.5 e quelle precedenti non includono la correzione di CVE-2026-111357 e CVE-2026-118527. Ivanti raccomanda, sempre secondo Rapid7, di migrare dal ramo 22.8.X alla versione 25.1.1.3 o successiva. Se la migrazione non è immediatamente possibile, 22.8R2.6 è l’aggiornamento correttivo indicato per quel ramo.

Perché aggiornare non esclude una compromissione precedente

La patch corregge le vulnerabilità, ma non cancella eventuali attività già avvenute. Volexity riferisce che, nel caso investigato, l’attaccante ha eliminato tracce dai log e ha modificato codice in memoria, ripristinando poi alcune impostazioni. Per questo il rapporto avverte che l’Integrity Checker di Ivanti può non rilevare la compromissione osservata: un controllo senza segnalazioni, da solo, non conferma che l’apparato sia integro.

Volexity raccomanda verifiche forensi su memoria, rete e log, prestando attenzione alle richieste a /dana-na/auth/url_default/welcome.cgi quando il percorso richiesto non coincide con quello indicato nell’intestazione X-DSCGI-PATH. Rapid7 consiglia inoltre di preservare, se possibile, memoria e log prima di riavviare o ripristinare il dispositivo. Sono indicazioni per le verifiche tecniche, non la prova che un apparato specifico sia stato violato.

La sequenza degli eventi aiuta a distinguere le diverse fasi: Ivanti ha rilasciato le correzioni il 29 ottobre, CISA ha aggiunto le due vulnerabilità al KEV il 30 ottobre e Rapid7 ha pubblicato la propria analisi il 2 novembre 2026. Il prossimo passaggio per gli amministratori è verificare la versione installata e, se l’apparato era esposto prima dell’aggiornamento, valutare anche un’indagine sulla possibile compromissione.