Cisco Nexus 9000, falla critica consente l’esecuzione di codice root da remoto

Cisco ha corretto CVE-2026-20212, una vulnerabilità critica nell’integrazione Silicon One di dieci modelli di switch Nexus 9000 Series. Un attaccante remoto e non autenticato può inviare dati appositamente costruiti al dispositivo ed eseguire codice con privilegi root.

La falla ha un punteggio CVSS 9.8 su 10. Oltre alla compromissione dello switch, lo sfruttamento può provocare il crash del processo S1HAL e il conseguente riavvio dell’apparato, con possibili interruzioni della rete.

Cisco PSIRT ha pubblicato l’advisory il 2 settembre 2026 alle 16:00 GMT, classificandolo come versione 1.0 definitiva. La notizia è stata riportata il 3 settembre 2026.

Due porte TCP espongono il componente attraverso il VRF predefinito

CVE-2026-20212 dipende dall’accessibilità delle porte TCP 43210 e 43211 attraverso il default Layer 3 Virtual Routing and Forwarding, o L3 VRF, degli switch vulnerabili.

Un aggressore che riesca a raggiungere uno degli indirizzi IP configurati sul dispositivo può aprire una connessione verso queste porte e trasmettere input malevolo. Il sistema elabora tali dati in modo da consentirne l’esecuzione come codice con privilegi root.

Non servono credenziali, privilegi preliminari o interazioni da parte di un amministratore. La complessità dell’attacco è inoltre considerata bassa. Queste caratteristiche spiegano il punteggio CVSS quasi massimo:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Il vettore indica uno sfruttamento via rete, senza autenticazione e senza intervento dell’utente. Gli effetti potenziali sono elevati su confidenzialità, integrità e disponibilità, pur restando invariato l’ambito di sicurezza.

L’advisory Cisco aggiunge al vettore i parametri estesi E:X/RL:X/RC:X, mentre la valutazione base coincide con quella riportata nella scheda NVD. Gli altri riferimenti tecnici sono il Cisco Bug ID CSCwu32817 e la classificazione CWE-1327.

L’esecuzione di codice non è l’unico esito possibile. I pacchetti costruiti per sfruttare la vulnerabilità possono mandare in crash S1HAL, il processo legato al livello di astrazione hardware di Silicon One. Il guasto può determinare il reload dello switch, trasformando l’attacco anche in un’interruzione del servizio.

Cisco ha individuato il problema mentre il Technical Assistance Center gestiva un caso di supporto. Il PSIRT dichiara di non conoscere utilizzi malevoli o ulteriori annunci pubblici relativi alla vulnerabilità.

I dieci modelli Nexus 9000 vulnerabili

La falla non coinvolge indiscriminatamente l’intera famiglia Nexus 9000. Sono interessati soltanto dieci Product ID dotati di ASIC Silicon One:

• N9324C-SE1U
• N9348Y2C6D-SE1U
• N9364E-SG2-O
• N9364E-SG2-Q
• N9396T12C-SE1
• N9348Y12C-SE1
• N9396Y12C-SE1
• N9336C-SE1
• N9K-C9804
• N9K-C9808

Gli amministratori possono identificare il modulo installato eseguendo dalla CLI:

show module

Tra le informazioni restituite compare il campo Model, che deve essere confrontato con l’elenco dei PID vulnerabili. Cisco mostra, per esempio, un apparato che identifica il proprio modulo come N9336C-SE1:

switch# show module
Mod Ports Module-Type                                  Model        Status
--- ----- -------------------------------------------- ------------ --------
1   36    36x40/100G QSFP28 Ethernet Module            N9336C-SE1   ok

Un inventario basato soltanto sul nome generale “Nexus 9000” non è quindi sufficiente. Occorre verificare il PID effettivo di ogni apparato, compresi chassis e moduli presenti nelle infrastrutture più articolate.

Quali piattaforme Cisco non sono coinvolte

Cisco ha escluso dalla vulnerabilità tutti i Nexus 9000 diversi dai dieci modelli indicati. Non sono vulnerabili neppure i Nexus 9000 Series Fabric Switches utilizzati in modalità ACI.

L’elenco delle famiglie confermate non interessate comprende inoltre:

• Nexus 3000 Series e Nexus 7000 Series;
• MDS 9000 Series Multilayer Switches;
• Firepower 1000, 2100, 4100 e 9300;
• Secure Firewall 200, 1200, 3100, 4200 e 6100;
• UCS 6300, 6400, 6500 e 6600 Series Fabric Interconnects;
• UCS X-Series Direct Fabric Interconnect 9108 100G.

La modalità operativa conta. Un Nexus 9000 impiegato come Fabric Switch in ACI rientra esplicitamente tra i prodotti esclusi, mentre un apparato con uno dei PID vulnerabili deve essere controllato e aggiornato.

La patch è disponibile, ma la release va verificata

Cisco ha distribuito aggiornamenti software per correggere CVE-2026-20212. Non sono però stati resi noti numeri univoci di release o build corrette applicabili a tutti i modelli interessati.

Gli amministratori devono utilizzare il Cisco Software Checker, selezionare la piattaforma e inserire la versione NX-OS installata. Lo strumento restituisce la voce First Fixed, cioè la prima release che risolve la vulnerabilità scelta.

Quando sul dispositivo sono presenti più problemi di sicurezza, può essere disponibile anche Combined First Fixed. Questa indicazione identifica la prima versione che corregge congiuntamente tutte le vulnerabilità considerate dal controllo.

Prima dell’upgrade è opportuno consultare anche le raccomandazioni Cisco sulle release consigliate. La versione da installare deve essere scelta in funzione dello specifico modello Nexus 9000, della configurazione e dei requisiti operativi della rete.

L’aggiornamento a una release corretta resta il rimedio definitivo. Workaround, filtri e protezioni aggiuntive servono soltanto a ridurre temporaneamente l’esposizione.

iACL e Live Protect per contenere il rischio

Quando non è possibile aggiornare immediatamente, Cisco propone un workaround basato su infrastructure access control list, o iACL. Le regole dovrebbero consentire esclusivamente il traffico di gestione e control plane realmente necessario verso lo switch.

In alternativa, le iACL possono bloccare esplicitamente i pacchetti TCP diretti a un indirizzo IP locale del dispositivo sulle porte:

TCP/43210
TCP/43211

Il filtro impedisce agli host non autorizzati di raggiungere i servizi esposti attraverso il default L3 VRF. Va applicato considerando con attenzione l’architettura di gestione, le reti di monitoraggio e gli strumenti che comunicano legittimamente con lo switch.

Cisco ha testato con successo il workaround iACL nel proprio ambiente. Il vendor avverte comunque che ACL troppo restrittive possono interferire con funzionalità o prestazioni, quindi le regole devono essere validate prima dell’introduzione in produzione.

È disponibile anche un Live Protect shield specifico per CVE-2026-20212 in Cisco NX-OS. La protezione può coprire il periodo necessario a pianificare la manutenzione, ma non sostituisce l’installazione della release corretta.

Controlli prioritari per gli amministratori di rete

Le organizzazioni dovrebbero partire dall’inventario, eseguendo show module su ogni Nexus 9000 e cercando i dieci PID interessati. Per gli apparati vulnerabili occorre poi rilevare la release NX-OS e verificarla con il Software Checker.

Fino all’aggiornamento, è consigliabile controllare che le porte TCP 43210 e 43211 non siano raggiungibili da reti non necessarie. Le connessioni verso tali porte meritano inoltre una verifica nei log e nei dati di telemetria disponibili, soprattutto se provenienti da segmenti inattesi.

Non sono stati forniti indicatori di compromissione specifici. Un crash anomalo di S1HAL o un reload inspiegato richiedono comunque analisi, perché rientrano tra i possibili effetti dello sfruttamento, pur non costituendone da soli una prova.

Nelle informazioni NVD disponibili non compare alcuna indicazione relativa al catalogo CISA Known Exploited Vulnerabilities. Non risultano quindi né una data di inserimento nel KEV né una scadenza federale di remediation. Cisco, inoltre, non ha segnalato attacchi osservati.

L’assenza di sfruttamento noto non riduce però le capacità tecniche della falla: accesso remoto, nessuna autenticazione, privilegi root e possibile riavvio dello switch impongono una correzione rapida sugli apparati effettivamente coinvolti.