In sintesi
L’aggiornamento NX-OS di ottobre 2026 di Cisco corregge falle critiche che possono dare a un attaccante i privilegi di root sugli switch da data center Nexus, sugli switch di storage MDS e sui fabric interconnect UCS. La falla della NX-API, CVE-2026-76471, ha CVSS 9.8 e non richiede credenziali se l’API è attiva. Cisco ha inoltre raggruppato decine di bug trovati internamente in sei CVE, due delle quali con 9.8. Non risultano sfruttamenti e non esistono workaround.
Per i team software il problema è l’automazione. La NX-API è disattivata di default, ma viene spesso abilitata perché le pipeline possano configurare la rete come codice. Se i vostri strumenti cloud e DevOps distribuiscono VLAN, rotte o modifiche di fabric sugli switch Nexus, è proprio questa interfaccia la prima da aggiornare.
Che cosa ha pubblicato Cisco?
Il 7 ottobre 2026 Cisco ha pubblicato due tipi di advisory NX-OS. Il primo è classico: CVE-2026-76471, un heap overflow nella NX-API, l’interfaccia HTTP e JSON-RPC con cui script e controller gestiscono uno switch. Una sola richiesta costruita ad arte verso una NX-API esposta può eseguire codice come root. Sui fabric interconnect UCS 6300 la stessa falla è raggiungibile tramite l’API XML di UCS Manager, ma solo con credenziali valide a bassi privilegi.
Il secondo è nuovo nella forma. Cisco lo chiama «software hardening release»: una revisione interna ha trovato molte vulnerabilità e, invece di un advisory per bug, Cisco le ha raggruppate per classe di debolezza assegnando una CVE a ogni classe. Il punteggio di ciascuna CVE riflette il bug peggiore che contiene. Secondo Cisco, i problemi sono stati individuati con i processi di test esistenti «e con modelli di IA di frontiera». BleepingComputer e SecurityWeek segnalano anche falle critiche separate nelle funzioni Next Generation OAM e MPLS OAM, oltre a bug critici nel license manager on-premises di Cisco.
Quali switch e fabric sono esposti?
L’hardening release copre gli switch di storage MDS 9000, i Nexus 3000 e 7000, i Nexus 9000 sia in modalità standalone sia ACI, i fabric interconnect UCS dalla serie 6300 alla 6600 e l’UCS X-Series Direct 9108 100G, a prescindere dalla configurazione. In pratica riguarda la maggior parte dei data center on-premises e degli spazi in colocation basati su apparati Cisco, compresa la fabric sotto i cluster VMware, Kubernetes e di storage.
Il rischio immediato più alto è dove una funzione allarga la superficie d’attacco: NX-API raggiungibile da una rete di server o di automazione, NGOAM usato con overlay SRv6 o VXLAN, oppure MPLS OAM. Le release corrette sono elencate per piattaforma nell’advisory di Cisco; i rami più vecchi come NX-OS 9.3 su MDS e 8.3 su Nexus 7000 non hanno fix e devono passare a una release supportata.
Cosa significa per i team software negli Stati Uniti e in Europa
Primo, il network-as-code ha reso l’API di gestione parte della vostra superficie d’attacco. Strumenti come Ansible e i provider Terraform per NX-OS dialogano con gli switch tramite NX-API, quindi l’API viene abilitata su tutto il parco e aperta a runner CI e jump host. Un bug root senza autenticazione su questo percorso significa che un build agent compromesso o una VLAN di gestione piatta possono trasformarsi nel controllo della fabric del data center. Limitate la NX-API a indirizzi di gestione dedicati e trattate credenziali e runner dell’automazione come asset tier-zero.
Secondo, la ricerca di bug assistita dall’IA cambia la natura delle giornate di patch. Una CVE ora rappresenta una classe di bug, non un singolo difetto. Le dashboard che contano le CVE o confrontano firme di exploit sottostimeranno il lavoro, e Cisco prevede hardening release simili per IOS XE, IOS XR, ASA e Secure Firewall, con advisory programmati il primo e il terzo mercoledì di ogni mese. Pianificate finestre di change fisse attorno a questo calendario invece di reagire a ogni pacchetto.
Terzo, senza workaround serve una vera pianificazione dei fermi. L’aggiornamento di switch e fabric interconnect interrompe il traffico se l’architettura non è ridondata. Per le entità finanziarie dell’UE soggette a DORA e per i soggetti essenziali NIS2, la capacità di aggiornare rapidamente l’infrastruttura critica è una delle domande delle autorità di vigilanza. Registrate cosa era vulnerabile, quando è stato corretto e perché un apparato ha dovuto attendere.
Cosa significa per i data center in Italia?
In Italia molte fabric Nexus aziendali girano in colocation nei principali poli di data center, a partire dall’area di Milano, dove le finestre di manutenzione vanno concordate con il provider. Chi gestisce questi apparati con Ansible o Terraform fa bene a pianificare subito l’aggiornamento con il partner di colocation, invece di aspettare la prossima finestra trimestrale. Con il recepimento della NIS2 (d.lgs. 138/2024) la platea dei soggetti tenuti a gestire le vulnerabilità in modo documentato si è allargata a migliaia di aziende registrate presso l’Agenzia per la Cybersicurezza Nazionale (ACN): conviene collegare gli avvisi del CSIRT Italia allo stesso canale di allerta degli advisory Cisco.
Per banche, assicurazioni e intermediari vigilati, DORA aggiunge l’obbligo di dimostrare come viene gestito un rischio ICT di questo tipo, e un bug root senza autenticazione nel cuore della rete di data center ne è un esempio da manuale. Un registro delle versioni prima e dopo l’aggiornamento, con data per ogni apparato, è la prova più semplice da presentare in sede di verifica.
Cosa fare adesso?
- Inventariare il parco. Elencare ogni Nexus, MDS e fabric interconnect UCS con la relativa release NX-OS o UCS, compresi gli apparati di laboratorio, di disaster recovery e in colocation che ricevono poca attenzione.
- Individuare NX-API, NGOAM e MPLS OAM. Verificare su quali apparati queste funzioni sono attive e chi le usa. Disattivare tutto ciò che nessuna pipeline o controller usa davvero.
- Ridurre l’esposizione. Limitare la NX-API alle interfacce di gestione e a indirizzi sorgente specifici con access list, e ruotare le credenziali usate dall’automazione. Usare la protezione Live Protect solo come soluzione ponte.
- Aggiornare a ondate. Partire dagli apparati che espongono la NX-API, poi il resto del parco. Testare prima la release di destinazione nella pipeline di automazione, perché moduli e provider possono comportarsi diversamente dopo aggiornamenti importanti di NX-OS.
- Conservare le evidenze. Archiviare versioni prima e dopo, ticket di change e data di correzione di ogni apparato, per audit e future richieste di ACN o dell’autorità di vigilanza.
Domande frequenti
Che cos’è CVE-2026-76471?
È un heap buffer overflow nella funzione NX-API di Cisco NX-OS, con CVSS 9.8. Un attaccante remoto non autenticato può inviare una richiesta HTTP costruita ad arte a una NX-API attiva su uno switch Nexus 3000 o Nexus 9000 in modalità standalone ed eseguire codice come root. Sui fabric interconnect UCS 6300 il bug è raggiungibile tramite l’API XML di UCS Manager ma richiede credenziali valide a bassi privilegi.
La NX-API è attiva sui miei switch Nexus?
La NX-API è disattivata di default sugli switch Nexus 3000 e 9000. Viene spesso abilitata perché strumenti di automazione, controller e script possano gestire lo switch via HTTP o HTTPS. Il comando «show feature | include nxapi» mostra su ogni apparato se è attiva.
Che cos’è l’hardening release di Cisco NX-OS?
È un nuovo tipo di advisory Cisco pubblicato il 7 ottobre 2026. Cisco ha revisionato NX-OS internamente, con i test esistenti e modelli di IA di frontiera, e ha raggruppato le vulnerabilità trovate in sei CVE per classe di debolezza. Ogni CVE riporta il punteggio del bug peggiore della sua classe; CVE-2026-76455 e CVE-2026-76459 hanno 9.8. Si applica alle release interessate indipendentemente dalla configurazione.
Le vulnerabilità di Cisco NX-OS vengono sfruttate?
Cisco afferma di non essere a conoscenza di exploit pubblici o di usi malevoli alla data degli advisory di ottobre 2026. Non esistono workaround, quindi l’aggiornamento a una release corretta è l’unico rimedio completo. Per la falla NX-API Cisco ha rilasciato una protezione temporanea Live Protect.
Quali release di NX-OS correggono le vulnerabilità?
Per Nexus 3000 e Nexus 9000 in modalità NX-OS standalone l’hardening release indica 10.3(10), 10.4(8), 10.5(6) e 10.6(4) come prime release corrette. MDS 9000, Nexus 7000, Nexus 9000 in modalità ACI e fabric interconnect UCS hanno proprie release corrette nell’advisory di Cisco, e alcuni rami più vecchi devono migrare a una release supportata.
Fonti
Cisco — Cisco NX-OS Software Security Hardening Release: October 2026
Cisco — Cisco NX-OS Software NX-API Remote Code Execution Vulnerability (CVE-2026-76471)
Cisco — Transition to a Risk-Based Vulnerability Disclosure Model
BleepingComputer — Cisco warns of critical flaws allowing Nexus switch takeover
SecurityWeek — Cisco Patches a Dozen Critical Vulnerabilities