Cisco ISE CVE-2026-76460: bypass di autenticazione e root sull'autorità di identità

Il 16 settembre 2026 CISA ha aggiunto CVE-2026-76460 al catalogo Known Exploited Vulnerabilities, imponendo alle agenzie federali statunitensi di applicare la patch entro il 19 settembre o di mettere il prodotto offline. Tre giorni di scadenza su una falla CVSS 10.0 sono il modo in cui CISA comunica che lo sfruttamento è reale, in corso e non teorico. Il prodotto colpito è Cisco Identity Services Engine — l'apparato che decide chi ha diritto di accedere alla rete. Un attaccante non autenticato che raggiunge la sua API può bypassare l'autenticazione ed eseguire comandi come root. Non esiste workaround. L'unica soluzione è la patch.

Perdere un web server per un CVSS 10.0 è grave. Perdere l'apparato che emette le decisioni di identità della rete è una categoria di gravità diversa, perché tutto ciò che sta a valle si fida di quello che quell'apparato dichiara.

Che cosa è davvero CVE-2026-76460

Cisco descrive la falla come controlli di autenticazione insufficienti su un endpoint API. In termini concreti: un insieme specifico di richieste API che dovrebbero richiedere una sessione valida non ne verificano nessuna. Un attaccante remoto e non autenticato invia una richiesta HTTP costruita ad hoc all'interfaccia di gestione, l'endpoint risponde come se il chiamante fosse un amministratore e la catena termina in esecuzione di comandi come root sull'apparato sottostante (Help Net Security, 17 set 2026).

Il raggio d'azione è volutamente ampio. Cisco dichiara che il bug colpisce Cisco ISE e ISE Passive Identity Connector (ISE-PIC) dalle release 3.0 alla 3.5, indipendentemente dalla configurazione dell'apparato (The Hacker News, 17 set 2026). Non c'è un'opzione di hardening che ti tolga dallo scope, non c'è una funzione da disattivare. Se l'API di gestione è raggiungibile e la versione è vulnerabile, sei esposto.

Non è la prima volta che ISE è il bersaglio anziché la guardia. Nel luglio 2025 gli attaccanti hanno sfruttato un altro zero-day di ISE, CVE-2025-20337, per installare una web shell in-memory che Cisco ha poi chiamato IdentityAuditAction — un impianto Java che girava interamente in memoria ed eludeva la detection dell'apparato stesso (BleepingComputer). Il precedente conta, perché racconta cosa fa un attaccante competente dopo aver preso possesso di un nodo ISE, e dove si nasconde.

Perché un bypass di autenticazione non lascia impronte

Ecco il problema operativo che rende questo CVE peggiore di quanto il suo CVSS già suggerisca. L'attacco è un bypass di autenticazione. Non c'è un login fallito, nessun pattern di brute-force, nessun accesso riuscito anomalo che un SIEM possa correlare — perché l'attaccante non si è mai autenticato. Il senso stesso della vulnerabilità è che il livello di identità viene saltato. L'evento che normalmente cercheresti non esiste.

E poi peggiora. Poiché l'exploit porta l'attaccante a root, i log dell'apparato diventano scrivibili dall'attaccante. La guida alla compromissione di Cisco è insolitamente candida su questo punto. Dice ai difensori di controllare access.log su ogni nodo di deployment in cerca di username sospetti — e nella stessa frase di incrociare i log di rete e firewall in cerca di upload inattesi verso indirizzi IP esterni o download da indirizzi malevoli, proprio perché un attaccante con privilegi root potrebbe aver cancellato l'evidenza locale (Help Net Security).

Rileggilo. Il vendor ti sta dicendo che la telemetria on-box non è affidabile dopo la compromissione, e che l'evidenza sopravvissuta vive sul filo.

"Mostrami l'audit log di ISE per quella finestra." "È pulito." "Pulito perché non è successo niente, o pulito perché qualcuno con root l'ha modificato?" "…è la stessa domanda, vero."

Un apparato di identità a cui è stato dato root è la sorgente di log di cui puoi fidarti meno, perché il suo compito è proprio essere il registro autorevole di chi ha fatto cosa. La web shell in-memory del 2025 è la dimostrazione dell'evasione: non ha lasciato nulla su disco da cercare con un grep.

L'autorità di identità è la scatola peggiore da perdere

ISE non è un logger passivo. È il cervello RADIUS/TACACS+ e il motore di policy per il controllo degli accessi alla rete. Decide se un endpoint entra nella VLAN aziendale, in quella di quarantena o in nessuna. Autorizza porte di switch e sessioni VPN. Custodisce — o intermedia — le credenziali e le regole di posture che presidiano la rete.

Un attaccante con root su ISE non ha semplicemente un punto d'appoggio. Ha la capacità di:

• Autorizzare endpoint canaglia — creare accesso di rete valido per dispositivi che non dovrebbero mai superare la posture.
• Manipolare la policy di autenticazione — abbassare o disattivare MFA e controlli di posture per account scelti (MITRE ATT&CK T1556, Modify Authentication Process).
• Creare o elevare account sull'apparato stesso (T1098, Account Manipulation).
• Sottrarre segreti — RADIUS shared secret, chiavi TACACS+, credenziali di integrazione verso Active Directory e la CA.

Ognuna di queste azioni produce autenticazioni a valle dall'aspetto legittimo. Una volta compromessa l'autorità di identità, "questa sessione si è autenticata correttamente" smette di essere una rassicurazione e diventa rumore. Non puoi risolvere con un audit la compromissione di chi fa l'audit. Ti resta il comportamento: il traffico che i dispositivi appena autorizzati dall'attaccante generano davvero, e i beacon che l'apparato stesso, ora root, invia verso l'esterno.

Remediation

Tratta qualsiasi ISE raggiungibile da internet o dalla DMZ, in esecuzione su una release 3.0–3.5 non patchata, come presunto-compromesso finché non l'hai investigato e ripulito. La scadenza federale era il 19 settembre; lo sfruttamento la precede.

1. Sono colpito?

• Verifica versione e livello di patch: dalla CLI admin, show version. Qualsiasi nodo ISE o ISE-PIC su 3.0–3.5 sotto la patch corretta (tabella sotto) è vulnerabile indipendentemente dalla configurazione.
• Determina la raggiungibilità dell'interfaccia di gestione/API. Lo sfruttamento è una richiesta HTTP remota verso quell'interfaccia — se è raggiungibile da un segmento non fidato o da internet, sei nel percorso di sfruttamento attivo, non in quello teorico.

2. Patch — release corrette esatte

Cisco non fornisce workaround. Aggiorna almeno alla prima patch corretta del tuo ramo (advisory Cisco via The Hacker News):

Ramo ISE / ISE-PIC	Prima release corretta
3.0 e precedenti	Nessuna patch — migrare a un ramo corretto
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

3. Non puoi patchare subito? Controlli compensativi

• Togli l'interfaccia di gestione/API da qualsiasi percorso non fidato adesso. Limita l'accesso amministrativo e API a una rete di management dedicata con ACL rigide; l'exploit è una richiesta di rete, quindi rimuovere il percorso di rete rimuove il percorso di exploit. È un tampone, non una cura — patcha dietro di esso.
• Termina l'amministrazione di ISE dietro un bastion host; nega la raggiungibilità diretta dai segmenti utente e DMZ.

4. Caccia alla compromissione

L'evidenza on-box è necessaria ma non sufficiente, perché root può cancellarla. Cerca su entrambi i piani:

• Sull'apparato: esamina access.log su ogni nodo di deployment in cerca di username anomali o fittizi — l'indicatore di Cisco stesso, es. show logging application ise-kong/access.log | include dummyuser. Cerca account admin inattesi e modifiche di configurazione (T1070, Indicator Removal — aspettati buchi dove i log sono stati cancellati).
• Sul filo (il piano affidabile): cerca connessioni in uscita dal nodo ISE stesso verso ASN o IP mai visti prima (T1041/T1567, esfiltrazione e C2 su web service); upload inattesi verso indirizzi esterni; pattern di traffico di shell interattiva da un apparato che normalmente parla solo RADIUS/TACACS+/LDAP/SQL. L'exploit iniziale è T1190 (Exploit Public-Facing Application); attenzione alla web shell in-memory in stile 2025, che per costruzione non lascia nulla su disco.
• Correla a valle: autorizzazione improvvisa di endpoint nuovi o non conformi, modifiche di policy MFA/posture, nuovi NAD (network access device) aggiunti a ISE.

5. Bonifica e verifica

La guida di Cisco per i nodi sospetti-compromessi è re-imaging, non pulizia — un impianto in-memory e la manomissione a livello root rendono inaffidabile la rimozione chirurgica. Dopo il re-imaging a una release corretta:

• Ruota tutto ciò che ISE intermediava: RADIUS shared secret, chiavi TACACS+, credenziali di join AD, segreti di integrazione PKI/CA, password admin.
• Invalida sessioni amministrative e token API attivi.
• Conferma la pulizia dopo patch e rotazione osservando il filo per un ciclo completo: l'apparato deve tornare al suo profilo di protocollo di base, senza anomalie in uscita.

Dove il filo è l'unico testimone onesto

Tutto quanto sopra converge su un unico fatto scomodo: quando l'apparato che possiede le tue decisioni di identità viene messo a root, i suoi log sono modificabili dall'avversario, e un bypass di autenticazione significa che non c'è mai stato un login da registrare. Il consiglio di compromissione dello stesso vendor — vai a guardare i log di rete e firewall — è l'ammissione che l'unica evidenza di cui puoi fidarti è quella che l'attaccante non può toccare. Quell'evidenza è il traffico.

È il caso per cui è nato il motore di AI Traffic Analysis di Zero Hunt. Esegue un modello di deep learning proprietario con quattro inference head paralleli — traffico sospetto, classificazione malware, identificazione del tipo di attacco e fingerprinting applicativo — sulla GPU dell'appliance con un baseline di 2.7+ Gbit/s, interamente on-prem, senza alcun callback verso il cloud. L'head di fingerprinting applicativo sa che aspetto ha la conversazione normale di un nodo ISE: RADIUS, TACACS+, LDAP, la replica del suo database. Una shell interattiva, un beacon verso un ASN mai visto o un upload di file che lascia quello stesso host sono anomali nel momento in cui compaiono — mentre stanno accadendo, non nel digest SIEM del mattino dopo, e a prescindere da come l'access.log dell'apparato sia stato riscritto. Quando l'autorità di identità è essa stessa l'asset compromesso, il comportamento sul filo è l'unica verità di base che ti resta.

Due capacità chiudono il cerchio. Poiché l'exploit è un problema di raggiungibilità — una richiesta costruita che deve raggiungere l'API di gestione — il pentest generativo a 10 agenti di Zero Hunt risponde alla domanda che il CVSS non può porre: questa specifica interfaccia ISE è raggiungibile da un punto d'appoggio realistico nella tua topologia, e il bypass atterra davvero sulla tua build? Una campagna change-triggered parte entro un'ora dalla comparsa di una nuova interfaccia ISE sul perimetro, scrive una sonda per-target con un modello locale anziché con un PoC pubblico, la valida nell'AI Gym prima che tocchi la produzione e firma il risultato — raggiungibile dalla DMZ — con una catena di evidenza ECDSA, prova e non congettura. E poiché ISE ricade in pieno nello scope di NIS2 e DORA come infrastruttura di identità critica, quello stesso finding si mappa una volta sola su tutti i 32 framework di compliance, firmato al momento della scrittura per l'auditor che chiederà come lo sapevi.

Un CVSS 10.0 sull'autorità di identità non è un ticket di patch. È una domanda sul fatto che tu lo vedresti anche solo — e la risposta onesta dipende da dove stai guardando quando i log tacciono.