Una falla nell’autenticazione delle API di Cisco ISE apre una via remota all’accesso root

Cisco ha rilasciato correzioni d’emergenza per una vulnerabilità zero-day critica che interessa Identity Services Engine e ISE Passive Identity Connector. La falla è già oggetto di sfruttamento e gli attacchi riusciti possono portare all’esecuzione di comandi con privilegi root.

Identificata come CVE-2026-76460, la vulnerabilità ha ottenuto il punteggio CVSS massimo, pari a 10,0. Il problema interessa Cisco ISE e ISE-PIC indipendentemente dalla configurazione dei prodotti.

Cisco ha pubblicato il proprio avviso alle 16:00 GMT del 16 settembre 2026. Lo stesso giorno, CISA ha aggiunto la vulnerabilità al catalogo delle vulnerabilità note e sfruttate e ha fissato al 19 settembre 2026 il termine per la correzione da parte delle agenzie federali statunitensi.

Non esiste una soluzione alternativa completa. Gli amministratori devono installare la versione corretta appropriata e verificare gli appliance interessati alla ricerca di tracce di eventuali compromissioni precedenti.

Un’API di gestione non applica correttamente l’autenticazione

CVE-2026-76460 è dovuta a un endpoint API di ISE che non applica controlli di autenticazione adeguati. Cisco associa il problema a CWE-648, l’uso errato di API privilegiate.

Un attaccante remoto non autenticato può inviare a un appliance interessato una richiesta appositamente predisposta. La richiesta può aggirare le protezioni dell’interfaccia di gestione basata sul Web e fornire un accesso non autorizzato al sistema.

Per sfruttare la vulnerabilità non servono credenziali rubate, un account esistente o l’interazione di un amministratore. La complessità dell’attacco è inoltre considerata bassa: lo sfruttamento non dipende da condizioni di gara insolite né da prerequisiti difficili da soddisfare.

Il vettore CVSS 3.1 completo è:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H/E:X/RL:X/RC:X

La valutazione con ambito modificato riflette conseguenze che si estendono oltre il componente inizialmente vulnerabile. Riservatezza, integrità e disponibilità risultano tutte fortemente compromesse.

Cisco avverte che lo sfruttamento può consentire l’esecuzione di comandi come root. Con questo livello di privilegi, un intruso potrebbe modificare l’appliance, interromperne il funzionamento o manomettere le prove archiviate localmente. L’accesso root rende inoltre meno affidabile l’analisi post-incidente, perché un attaccante potrebbe eliminare i log o nascondere le tracce dell’intrusione.

Cisco identifica internamente la vulnerabilità come bug CSCww39530. L’identificativo dell’avviso è cisco-sa-ISE-ABP-VNSW7Tn5.

Ogni ramo di release ISE supportato richiede una patch specifica

I prodotti vulnerabili sono:

• Cisco Identity Services Engine
• Cisco ISE Passive Identity Connector

Cisco afferma che l’esposizione non dipende dalla configurazione del dispositivo. Le organizzazioni non devono quindi presumere che una modalità di distribuzione particolare, una funzionalità disabilitata o un’altra impostazione locale elimini il rischio.

La release corretta da installare dipende dal ramo software presente:

Release Cisco ISE o ISE-PIC installata	Prima release contenente la correzione
3.1	3.1 Patch 12
3.2	3.2 Patch 11
3.3	3.3 Patch 12
3.4	3.4 Patch 7
3.5	3.5 Patch 4

Gli amministratori che utilizzano uno di questi rami devono installare la patch indicata o una release corretta successiva disponibile per quel ramo.

Cisco ISE Software Release 3.0 ha raggiunto la fine della manutenzione software. Non è disponibile una patch correttiva per questa versione; le organizzazioni che la utilizzano ancora devono quindi migrare a una release supportata che includa la correzione.

Il riferimento autorevole per la corrispondenza tra release è l’avviso di sicurezza del fornitore. Le organizzazioni con distribuzioni distribuite devono inventariare ogni nodo, senza limitarsi a controllare il sistema di amministrazione principale.

Gli attacchi in corso impongono alle agenzie federali una finestra di tre giorni per la correzione

Il Product Security Incident Response Team di Cisco ha confermato che la vulnerabilità viene sfruttata attivamente. L’azienda ha scoperto il problema durante la gestione di un caso presso il Cisco Technical Assistance Center, non nell’ambito di una valutazione interna programmata.

Non è stato identificato alcun attore della minaccia. Cisco non ha collegato l’attività a un’organizzazione criminale, a un’operazione sponsorizzata da uno Stato o a un gruppo ransomware noto, e le informazioni disponibili non descrivono gli obiettivi degli attaccanti.

CISA ha aggiunto CVE-2026-76460 al catalogo delle vulnerabilità note e sfruttate il 16 settembre 2026. Le agenzie federali devono completare la correzione richiesta entro il 19 settembre 2026.

La voce del catalogo KEV impone alle agenzie di applicare le misure di mitigazione di Cisco nel rispetto della BOD 26-04, “Prioritizing Security Updates Based on Risk”, e dei requisiti di CISA per il triage forense. Le disposizioni applicabili della BOD 26-04 riguardano anche i servizi cloud. Se la mitigazione non è disponibile, CISA ordina agli enti interessati di interrompere l’uso del prodotto.

Il triage forense è esplicitamente richiesto. Non è ancora noto se la vulnerabilità venga utilizzata in campagne ransomware.

La scadenza ravvicinata riflette lo sfruttamento osservato, non un percorso d’attacco soltanto teorico. I responsabili degli asset devono inoltre valutare se ogni appliance è esposto a Internet o comunque raggiungibile da reti dalle quali un attaccante potrebbe inviare richieste al relativo piano di gestione.

Le iACL possono ridurre l’esposizione, ma non eliminano la falla

Cisco non ha individuato una soluzione alternativa in grado di risolvere completamente CVE-2026-76460. L’installazione di una release corretta è l’unica misura di correzione indicata.

Durante l’applicazione delle patch, gli amministratori possono distribuire liste di controllo degli accessi all’infrastruttura, o iACL, per limitare il traffico diretto verso l’appliance interessato. Questi controlli dovrebbero consentire soltanto le connessioni di gestione e del piano di controllo necessarie, provenienti da sistemi e reti esplicitamente autorizzati.

Questa misura può ridurre i percorsi disponibili per un attaccante remoto, soprattutto quando i servizi di gestione erano ampiamente raggiungibili. Non corregge però la logica di autenticazione inadeguata dell’endpoint API.

La priorità dovrebbe andare ai sistemi esposti a Internet e agli appliance raggiungibili da segmenti di rete meno affidabili. Tuttavia, la sola collocazione nella rete interna non dimostra che il sistema sia al sicuro. Una workstation, un server o un account di accesso remoto compromesso potrebbe offrire a un attaccante la posizione di rete necessaria per raggiungere un’interfaccia di gestione non adeguatamente limitata.

Le restrizioni di rete dovrebbero restare attive anche dopo l’applicazione della patch, quando possibile dal punto di vista operativo. Forniscono un’ulteriore barriera intorno a un servizio infrastrutturale ad alto privilegio, ma non devono essere considerate un’alternativa all’aggiornamento software.

I difensori devono esaminare i log di ogni nodo

Cisco raccomanda di esaminare i dati di access.log alla ricerca di nomi utente e attività API sospetti. In una distribuzione ISE distribuita, gli investigatori devono controllare ogni nodo, perché le voci rilevanti potrebbero non comparire nel sistema principale o centrale.

Cisco fornisce questo esempio per la ricerca nel log del gateway API:

admin#show logging application ise-kong/access.log | include dummyuser

Il valore dummyuser è un esempio, non un indicatore completo di compromissione. Una corrispondenza può indicare un’attività malevola, ma gli investigatori dovrebbero verificarla confrontandola con le richieste circostanti, gli indirizzi di origine, i timestamp e il comportamento amministrativo previsto. Dovrebbero inoltre cercare altri nomi utente anomali, senza affidarsi soltanto a quel valore.

È possibile ottenere ulteriori log del gateway API raccogliendo un pacchetto di supporto con i log di debug inclusi. Cisco raccomanda di proteggere il pacchetto con la crittografia a chiave condivisa, di decrittografarlo nell’ambiente d’indagine e di esaminare i file presenti in:

./ise/logs/apigateway/access.log..gz

Le prove locali potrebbero essere incomplete. Poiché la falla può potenzialmente consentire l’esecuzione di comandi con privilegi root, un attaccante riuscito potrebbe modificare i log, eliminare file o nascondere in altro modo l’attività sull’appliance.

Gli investigatori dovrebbero correlare i dati di ISE con la telemetria conservata altrove, compresi gli eventi dei firewall e i dati sui flussi di rete. Dovrebbero cercare caricamenti in uscita non spiegati da un nodo ISE, download che coinvolgono indirizzi esterni sospetti e connessioni in entrata o in uscita insolite associate alla distribuzione.

In caso di sospetta compromissione, Cisco raccomanda vivamente di ricreare le immagini dei nodi interessati e, quando necessario, ripristinarli dai backup della configurazione. La semplice applicazione della patch non rimuove la persistenza né le modifiche non autorizzate che un attaccante potrebbe avere già introdotto.

Prima applicare la patch, poi verificare se l’accesso è già avvenuto

La risposta immediata si articola su due fronti paralleli: chiudere il percorso API vulnerabile e verificare se gli attaccanti lo abbiano raggiunto prima della correzione.

Gli amministratori devono identificare ogni nodo ISE e ISE-PIC, verificarne la release esatta, installare la patch corretta corrispondente e limitare il traffico di gestione con le iACL fino al completamento della distribuzione. Per i sistemi con release 3.0 è necessaria una migrazione, non una normale applicazione di patch.

Devono quindi preservare ed esaminare i log disponibili, raccogliere le prove provenienti dalla rete esterna e considerare una potenziale compromissione qualsiasi attività inspiegata sul piano di gestione. Quando gli indicatori suggeriscono uno sfruttamento riuscito, ricreare l’immagine del sistema è più sicuro che fare affidamento sull’integrità di un sistema che potrebbe essere stato controllato con privilegi root.