CVE-2026-20212: Cisco Nexus 9000 a rischio RCE root…

Cisco ha divulgato una vulnerabilità critica nei Nexus 9000 con Silicon One ASIC. CVE-2026-20212 ha CVSS 9.8 e consente esecuzione remota di codice come root senza

Cisco ha divulgato il 2 settembre 2026 una vulnerabilità critica nei Nexus 9000 Series Switches equipaggiati con Silicon One ASIC. CVE-2026-20212, con punteggio CVSS 9.8, consente a un attaccante remoto non autenticato di eseguire codice con privilegi root sfruttando due porte TCP esposte nel VRF Layer 3 di default. La falla rappresenta un rischio immediato per le infrastrutture di core datacenter, dove questi switch gestiscono il traffico spine-leaf di reti enterprise e cloud provider.

Punti chiave

CVE-2026-20212 ha CVSS 9.8: la massima criticità per un attacco remoto pre-autenticato che bypassa completamente i controlli di accesso.
Le porte TCP 43210 e 43211, normalmente nascoste, sono accessibili nel VRF Layer 3 di default a causa di un binding a indirizzo IP non restrittivo (CWE-1327).
L'input crafted inviato a queste porte viene eseguito come codice con privilegi root dal processo S1HAL, con possibile crash e reload del dispositivo.
La remediation non passa da una tabella statica di release ma richiede il Cisco Software Checker, e le mitigazioni temporanee hanno limiti di supporto per modello e versione.

Come funziona il vettore di attacco

La vulnerabilità risiede nel Silicon One Hardware Abstraction Layer (S1HAL), il componente che astrae l'interazione tra il sistema operativo NX-OS e il chipset Silicon One. Il problema è classificato come CWE-1327: binding a indirizzo IP non restrittivo. Il servizio di management associato al S1HAL si lega a un indirizzo IP ampio — tipicamente 0.0.0.0 o equivalente — anziché a un'interfaccia di management isolata.

Questa scelta architetturale espone le porte TCP 43210 e 43211 all'interno del VRF Layer 3 di default, il contesto di routing standard dove transita il traffico dati. Un attaccante con connettività IP al dispositivo può stabilire una connessione a queste porte senza autenticazione preventiva. L'input crafted inviato attraverso il canale viene processato dal S1HAL e eseguito con privilegi root, il livello più alto nel sistema operativo NX-OS.

L'advisory Cisco documenta che l'exploit può causare due effetti concatenati: l'arresto anomalo del processo S1HAL e il successivo reload del dispositivo. Questo implica non solo compromissione ma anche interruzione del servizio, con impatto sulla disponibilità di infrastrutture che spesso gestiscono centinaia di terabit al secondo.

Perché la patch non è in una tabella statica

Cisco ha strutturato la disclosure secondo un modello che il suo VP Information Security Russ Smoak ha definito orientato a chiudere la finestra tra disclosure e exploitation. La release dell'advisory il 2 settembre 2026 è sincronizzata con la disponibilità del software corretto, ma non in formato di tabella fissa. I 10 product identifier (PID) affetti — verificabili con il comando show module — corrispondono a modelli Nexus 9000 con Silicon One ASIC, ma la release specifica che corregge ciascuno dipende da parametri dinamici.

Per identificare il fix corretto, i team operativi devono utilizzare il Cisco Software Checker, un tool che incrocia PID, versione NX-OS corrente e release target. Questo approccio introduce latenza operativa: il tool richiede accesso al portale Cisco, connessione a infrastrutture esterne, e verifica manuale per ciascun dispositivo. In ambienti con centinaia di switch, questa dipendenza da tool vendor-specifico complica la pianificazione del change management, specialmente in finestre di manutenzione già saturate.

Secondo la verifica incrociata del CVE Program del 3 settembre 2026, citata da The Hacker News, le release affette sono 45, comprese tra NX-OS 10.3(1) e 10.6(3s). Il range ampio riflette la distribuzione temporale del Silicon One ASIC attraverso più generazioni di firmware.

Le mitigazioni temporanee e i loro limiti

L'advisory Cisco identifica due contromisure temporanee: infrastructure ACL (iACL) che bloccano il traffico verso le porte 43210 e 43211, e il Live Protect shield lp00031. Entrambe presentano vincoli operativi rilevanti.

Le iACL richiedono applicazione manuale su ciascun dispositivo e presupposto di conoscenza della topologia di routing per evitare blocchi indesiderati. Il Live Protect shield lp00031 è disponibile solo per NX-OS 10.6(3) e 10.6(3s), escludendo le release precedenti che compongono la maggior parte del parco installato. Inoltre, il meccanismo non è supportato sui modelli Nexus 9804 e 9808, due chassis modulari di fascia alta comunemente deployati in core network di grandi scale.

Questa frammentazione del supporto mitigativo significa che molti team non dispongono di workaround immediato applicabile universalmente. La rimozione della protezione temporanea e l'upgrade a release corretta rimangono l'unico percorso definitivo, ma la dipendenza dal Software Checker introduce un collo di bottiglia organizzativo che non può essere risolto con automazione interna.

Cosa fare adesso

Verificare immediatamente la presenza di Silicon One ASIC con il comando show module su ogni Nexus 9000; i 10 PID affetti sono elencati nell'advisory Cisco cisco-sa-n9k-s1-rce-EH8dEtr.
Consultare il Cisco Software Checker per identificare la release corretta specifica per ciascun PID e versione NX-OS installata, senza assumere che un unico firmware copra tutti i dispositivi.
Applicare iACL che blocchino il traffico in entrata verso TCP 43210 e 43211 su tutte le interfacce del VRF Layer 3 di default, verificando preventivamente che non esistano dipendenze funzionali su queste porte.
Valutare l'attivazione del Live Protect shield lp00031 solo per dispositivi su NX-OS 10.6(3) o 10.6(3s) che non siano modelli Nexus 9804/9808, riconoscendo che questa protezione è parziale e transitoria.

Il contesto della disclosure Cisco di settembre

La divulgazione del 2 settembre 2026 rientra in un batch più ampio di advisory Cisco che include hardening release per IOS XR e IOS XE, ma la vulnerabilità Nexus 9000 si distingue per severità e semplicità del vettore. La scoperta durante un caso di supporto TAC — non da un ricercatore esterno o bug bounty — suggerisce che il difetto ha attraversato più cicli di release senza rilevazione interna, nonostante l'esposizione di porte TCP in VRF dati rappresenti un pattern noto di rischio.

Cisco dichiara di non essere a conoscenza di uso malevolo al momento della disclosure. Questa assenza di exploitation confermata non riduce l'urgenza: la natura pre-autenticata del vettore, la criticità del target — switch di core datacenter — e la pubblicità della disclosure creano una finestra di opportunità misurata in giorni, non settimane. La citazione di Russ Smoak sull'obiettivo di chiudere la finestra disclosure-exploitation assume qui un significato operativo concreto: i team hanno tempo limitato per completare l'inventario dei PID affetti, navigare il Software Checker, e pianificare l'upgrade prima che la capacità di sfruttamento si diffonda.

La struttura della remediation, con la sua dipendenza da tool esterno e mitigazioni parziali, riflette una tensione crescente nella supply chain di sicurezza dei vendor di infrastruttura: la complessità del parco installato — 45 release, 10 PID, supporto mitigativo discontinuo — trasferisce il carico decisionale ai team operativi, che devono ora gestire non solo la vulnerabilità ma l'incertezza su quale patch applicare a quale dispositivo.

"A vulnerability in the Silicon One integration for Cisco Nexus 9000 Series Switches could allow an unauthenticated, remote attacker to execute code with root privileges" — Cisco Security Advisory cisco-sa-n9k-s1-rce-EH8dEtr

FAQ

Perché non posso semplicemente consultare una tabella di release fisse?
L'advisory Cisco non fornisce una matrice statica PID-release; il fix corretto varia per combinazione di hardware e firmware. Il Software Checker è l'unico canale autorizzato per determinare la versione target.

I Nexus 9000 in modalità ACI sono vulnerabili?
No. L'advisory Cisco esplicita che i dispositivi in ACI mode, così come Nexus 3000, Nexus 7000 e UCS X-Series, non sono affetti da CVE-2026-20212.

Il Live Protect shield è sufficiente come protezione a lungo termine?
No. Il shield lp00031 è una mitigazione temporanea con supporto limitato a specifiche versioni NX-OS e modelli; la remediation definitiva richiede l'upgrade a release indicata dal Software Checker.

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti

Fonti e riferimenti

Ricevi DeafLetter