Cisco IOS XE CVE-2026-20272: una command injection 9.8 senza workaround

Cisco ha puntato la propria AI su IOS XE e l'audit è tornato con sette classi di vulnerabilità nel software che fa girare una fetta enorme dei router e degli switch aziendali del mondo. La falla di punta, CVE-2026-20272, è una command injection da CVSS 9.8 che un attaccante non autenticato raggiunge via rete senza interazione dell'utente — e non esiste workaround. L'advisory è uscito il 5 agosto 2026 ed è stato revisionato il 2 ottobre per correggere le indicazioni sulle release corrette: motivo sufficiente per riverificare la build che state davvero eseguendo. L'unica buona notizia è chi l'ha trovata: il team Cisco, durante una revisione interna, non un attore ostile dentro la vostra rete.

In breve

CVE	CVE-2026-20272 (principale) · altre sei CVE-2026-20267 fino a CVE-2026-20273
Prodotto / versioni colpite	Cisco IOS XE Software in modalità autonoma e controller · treno di release da 16.6.2 a 26.1.3 · Catalyst 3650/3850 su 16.12 e precedenti non riceveranno patch
Corretta in	17.9.10 · 17.12.8 · 17.15.6 · 17.18.4 o 17.18.4a · 26.1.2 (advisory revisione 1.1, 2026-10-02)
CVSS	9.8 Critical per CVE-2026-20272 · 9.0 Critical per CVE-2026-20267 · altre cinque a 8.6 High — CVSS 3.1, assegnato da Cisco (CNA); NVD non ha dato un punteggio indipendente
Sfruttata attivamente	No — il PSIRT Cisco non è a conoscenza di annunci pubblici o uso malevolo; NVD SSVC exploitation: none al 2026-08-05
CISA KEV	Non presente (versione catalogo 2026.10.02)
PoC pubblico	Nessuno pubblico al 2026-10-03
Advisory ufficiale	cisco-sa-hardening-iosxe-V8NMuMZJ

Cosa ha davvero rilasciato Cisco

Questa è una hardening release, non la risposta a un incidente. Cisco ha raggruppato le falle per classe di debolezza, non per funzionalità di prodotto: controllo degli accessi improprio (CWE-284, il 9.0 di CVE-2026-20267), una classe di injection di comandi/OS/argomenti (CWE-74, il 9.8 di CVE-2026-20272), più le classi memory-buffer, ciclo di vita delle risorse, calcolo numerico, controllo di flusso e validazione dell'input, tutte a 8.6. Sette CVE, un unico treno di release, nessuna funzione da avere abilitata per rientrare nel perimetro.

Il metodo di scoperta è la parte su cui vale la pena soffermarsi. Secondo la copertura di gbhackers, Cisco dichiara che le falle «sono state scoperte durante una revisione di sicurezza interna approfondita delle release IOS XE, usando i processi di test esistenti di Cisco e modelli AI avanzati». In altre parole, il vendor ha puntato strumenti AI moderni sul proprio codice e ne è emerso un 9.8 rimasto latente in software già in produzione. È la stessa capacità che gli attaccanti stanno costruendo ora — ed è il motivo per cui lo stato «trovata internamente, non sfruttata» è un vantaggio con un orologio sopra, non una ragione per rimandare.

Due fatti operativi dominano tutto il resto. Primo, secondo securityonline.info e l'advisory stesso, non esistono workaround — l'aggiornamento è l'unica cura. Secondo, la revisione del 2 ottobre ha toccato esattamente la sezione «Vulnerable Products and Fixed Releases», quindi una decisione di patch presa ad agosto sulla tabella originale oggi potrebbe puntare alla build sbagliata.

Perché CVE-2026-20272 è quella che conta

Il vettore CVSS racconta tutto: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Raggiungibile via rete, bassa complessità, nessun privilegio, nessuna interazione, impatto pieno su riservatezza-integrità-disponibilità. Su un router di edge o uno switch di aggregazione WAN, la command injection nel sistema operativo sottostante non è un problema di fuga di dati — è un problema del tipo «l'attaccante ora possiede il dispositivo che vede tutto il traffico e applica la vostra segmentazione». La valutazione SSVC di NVD marca CVE-2026-20272 come automatable: yes con technical impact: total: se compare un exploit affidabile, è di quelli che si propagano in un colpo solo su ogni dispositivo raggiungibile.

La command injection su IOS XE non è nemmeno un evento anomalo. Il corpus di findings Cisco del nostro motore allinea un pattern chiaro — CVE-2021-1384 iniettava comandi come root attraverso l'ambiente di hosting IOx, e il ciclo 2025 ha aggiunto injection da CLI e da interfaccia web di gestione nello stesso OS. È una classe di debolezza ricorrente su una piattaforma dove una singola scatola con root è un pivot verso tutto ciò che sta dietro. Trattate CVE-2026-20272 come la capofila, ma applicate la patch all'intero bundle: la falla di controllo accessi 9.0 e le cinque 8.6 condividono lo stesso stato «correggibile solo con l'aggiornamento».

«Ha preso 9.8, ma non siamo esposti — i nostri router non sono su internet.»

I piani di gestione arrivano più lontano di quanto si creda: un jump host, un concentratore VPN compromesso, un segmento OT con un percorso piatto verso il core, il portatile di un consulente su una VLAN interna. «Non esposto su internet» restringe la superficie d'attacco; non la chiude. La domanda onesta non è è raggiungibile da internet ma quale dei miei dispositivi è raggiungibile da un punto in cui un attaccante può già stare — e a quella si risponde testando, non disegnando diagrammi.

Remediation

L'assenza di workaround rende il runbook insolitamente semplice da enunciare e insolitamente spietato da saltare.

1. Sono colpito? Confermate il treno in esecuzione e verificatelo sulla tabella corretta, non su quella letta ad agosto.

show version | include IOSXE|Version
show install summary        ! confermate l'immagine committata, non solo quella in boot

Qualunque dispositivo IOS XE in modalità autonoma o controller tra 16.6.2 e 26.1.3 rientra nel perimetro. I Catalyst 3650/3850 ancora su 16.12 o precedenti non riceveranno una correzione: per quelli serve un piano di migrazione, non una patch.

2. Patch — release corrette esatte. Aggiornate al target del vostro treno:

Treno attuale	Release corretta
17.9	17.9.10
17.12	17.12.8
17.15	17.15.6
17.18	17.18.4 o 17.18.4a
26.1	26.1.2

Verificate sull'advisory firmato prima di pianificare la finestra — la revisione 1.1 esiste proprio perché la prima tabella è stata corretta.

3. Non potete applicare la patch subito? Controlli compensativi. Cisco non ha pubblicato workaround, quindi non c'è un flag da attivare che chiuda il bug. Quello che potete fare è ridurre chi raggiunge le superfici vulnerabili mentre preparate l'aggiornamento: isolate il piano di gestione su una rete out-of-band dedicata, applicate ACL infrastrutturali perché solo host di gestione noti raggiungano il control plane, attivate il control-plane policing (CoPP) e disabilitate ogni servizio di gestione non in uso. Riducono la raggiungibilità (MITRE ATT&CK T1190, sfruttamento di un servizio esposto/di edge); non rimediano.

4. Caccia alla compromissione. Non esistono indicatori di compromissione pubblicati, perché non c'è sfruttamento noto — non andate a caccia di IOC che nessuno ha emesso, e diffidate di qualsiasi feed che ne offra. Quello che potete mettere a baseline ora, prima che atterri qualsiasi exploit, è la forma del post-exploitation su un dispositivo di rete: esecuzione inattesa di processi o shell sull'OS (T1059), modifiche di configurazione o immagine fuori dalla finestra di change (T1601, Modify System Image), account locali e regole ACL nuovi o alterati (T1686.002, manomissione del firewall su dispositivo di rete) e sessioni di gestione da host che non avevano mai toccato il dispositivo.

5. Bonifica e verifica. Su un dispositivo che aggiornate, confermate che l'immagine committata corrisponda alla build corretta, ruotate le credenziali che risiedevano sulla scatola o la transitavano e — il passo che quasi tutti saltano — ri-testate che lo specifico percorso vulnerabile sia davvero chiuso sulla vostra configurazione, invece di fidarvi che una stringa di versione equivalga a uno stato sicuro.

Quando a trovare è un'AI — e anche ad attaccare

La lezione più duratura qui non è CVE-2026-20272 in sé; è il metodo che l'ha trovata. Un vendor ha condotto un audit assistito dall'AI sul proprio codice e ha fatto emergere una falla critica che la revisione umana e gli strumenti precedenti avevano mancato release dopo release. Quella capacità non resta sul lato del difensore del tavolo. Lo stesso strumentario generativo che ha scritto il finding per Cisco è ciò che costruisce un exploit funzionante per un attaccante — ed è il motivo per cui un bug «trovato internamente, non ancora sfruttato» è una finestra, e l'ampiezza di quella finestra è quanto ci mette qualcuno a puntare lo stesso tipo di strumenti sul diff della patch.

È la domanda operativa che questo advisory lascia sulla scrivania: quale dei miei dispositivi IOS XE è davvero raggiungibile e sfruttabile, e in che ordine li correggo prima che la finestra si chiuda — ed è in pieno un problema di validazione continua e automatica, non un problema di foglio di calcolo per il tracciamento delle patch.

Una campagna Zero Hunt risponde direttamente alla metà «cosa faccio adesso». L'AI Remediation Advisor ordina i findings per sfruttabilità reale — prima CISA KEV, poi ciò che la campagna ha davvero provato sfruttabile sulla vostra rete, poi CVSS ed EPSS — così un 9.8 genuinamente raggiungibile sul vostro perimetro batte un 9.8 su un dispositivo che nessuno può toccare. Per questo advisory restituisce la build corretta esatta per treno (17.9.10, 17.12.8, 17.15.6, 17.18.4/a, 26.1.2), l'hardening del piano di gestione da applicare mentre preparate l'aggiornamento e note di rollout e rollback — poi ri-verifica la correzione con la stessa prova che aveva dimostrato l'esposizione, perché una stringa di versione è un'affermazione e una ri-esecuzione è una prova.

E sulla metà a cui la tabella delle versioni non può rispondere — questo dispositivo è raggiungibile, l'injection atterra davvero sulla mia build — il red team AI autonomo risponde all'offesa trovata dall'AI con un'offesa AI governata. Lo swarm a 10 agenti scrive una sonda per-bersaglio con un modello locale invece di aspettare un PoC pubblico, la ribacktesta nell'AI Gym prima che tocchi la produzione e gira black-box contro la vostra topologia reale. Gira on-premise sui modelli proprietari di Zero Hunt, con un operatore umano nel loop che autorizza ogni passo di sfruttamento, così nulla della vostra rete — né l'exploit che vi funziona — lascia l'apparato. L'AI di Cisco ha trovato questo bug una volta, in un audit interno. Il senso di un red team autonomo è far girare quel loop di continuo contro il vostro deployment, perché il prossimo 9.8 latente sia qualcosa che trovate voi sul vostro edge prima che chiunque altro punti la propria AI. Lo stesso mese, lo stack edge di Cisco ha prodotto un auth bypass attivamente sfruttato su SD-WAN Manager — il pattern è il punto.