Il 7 ottobre 2026 Cisco ha pubblicato una serie di avvisi di sicurezza che riguardano gli switch Nexus 3000 e Nexus 9000 in modalità NX-OS standalone: cinque vulnerabilità di validazione dell'input, tutte con punteggio CVSS 9.8, che un aggressore remoto e non autenticato potrebbe usare per eseguire codice con privilegi di root oppure, quando l'esecuzione non riesce, per mandare in crash i processi e provocare il riavvio del dispositivo. Al momento della pubblicazione Cisco dichiara di non essere a conoscenza di divulgazioni pubbliche né di sfruttamento malevolo: i difetti sono emersi da test di sicurezza interni. Non c'è quindi un'emergenza da incidente in corso, ma c'è una finestra di tempo, che di solito si chiude in fretta, in cui conviene muoversi.

Cosa è successo: le cinque CVE

Le vulnerabilità sono distribuite su tre advisory distinti e dipendono ciascuna da una funzione specifica che deve essere attiva sullo switch.

  • CVE-2026-76471 (advisory cisco-sa-napi-rce): riguarda NX-API, l'interfaccia HTTP per la gestione programmatica. Basta una richiesta HTTP costruita ad arte. NX-API è disattivata per impostazione predefinita su Nexus 3000 e 9000. L'avviso coinvolge anche le UCS 6300 Series Fabric Interconnect, ma lì lo sfruttamento richiede credenziali valide a basso privilegio tramite l'API XML di UCS Manager, per cui la gravità scende a "High".
  • CVE-2026-76485, CVE-2026-76486 e CVE-2026-76501 (advisory cisco-sa-ngoam-rce): colpiscono NGOAM (Next-Generation OAM). La prima richiede solo che NGOAM sia attivo; la seconda richiede in più SRv6 oppure NV Overlay con una VNI EVPN associata a un'interfaccia NVE con almeno un peer VTEP appreso; la terza richiede NGOAM e SRv6, quest'ultimo supportato solo da alcuni modelli Nexus 9000. In tutti i casi il vettore sono pacchetti IP costruiti ad arte inviati a un'interfaccia IP del dispositivo.
  • CVE-2026-76465 (advisory cisco-sa-moam-rce): riguarda MPLS OAM, disattivato di default, attivabile da un pacchetto MPLS echo-request costruito ad arte. Gli switch Nexus 9000 con ASIC Silicon One non supportano la funzione e non sono interessati.

Secondo Cisco non sono interessati gli switch Nexus 7000, gli MDS 9000 e i Nexus 9000 in modalità ACI, né Firepower, Secure Firewall e le UCS Fabric Interconnect fuori da quanto indicato per NX-API. Il punteggio per tutte e cinque è CVSS 3.1 9.8 con vettore AV:N/AC:L/PR:N/UI:N: rete, bassa complessità, nessuna autenticazione, nessuna interazione dell'utente.

Gli avvisi non elencano le release corrette in forma di tabella semplice: Cisco rimanda al Software Checker per individuare la prima versione fixed per la propria release. Come soluzione temporanea esistono i cosiddetti Live Protect shield, rilasciati per tutte e cinque le CVE, utili quando non si può aggiornare e riavviare subito. Cisco precisa che non esistono workaround che risolvano completamente le falle, ma disattivare la funzione interessata (no feature ngoam, no feature mpls oam, disattivazione di NX-API) elimina il vettore d'attacco.

Nello stesso ciclo di pubblicazioni Cisco ha anche corretto quattro vulnerabilità in Cisco License (ex Smart Software Manager), tra cui una con CVSS 10.0 (CVE-2026-76482, verifica impropria della firma crittografica) e una con CVSS 9.8 (CVE-2026-76480, autenticazione mancante). Qui non ci sono workaround e le versioni ancora marchiate Smart Software Manager non riceveranno patch: Cisco indica di passare a una release supportata (10-202609 contiene le correzioni). Il tema merita un controllo a parte, perché riguarda un componente di gestione delle licenze spesso dimenticato.

Cosa significa per le aziende italiane

Gli switch Nexus sono il cuore dei data center di banche, assicurazioni, grandi gruppi industriali, operatori telco e della sanità. Non sono apparati che si patchano con leggerezza: un aggiornamento NX-OS richiede una finestra di manutenzione, spesso un riavvio, la validazione con il fornitore di sistemi e, nelle architetture ridondanti, un piano di rolling upgrade. È proprio questo l'aspetto che trasforma una vulnerabilità "solo" teorica in un rischio reale: il tempo che passa tra la pubblicazione dell'advisory e l'effettiva messa in sicurezza è lungo e prevedibile, e gli attaccanti lo sanno.

Il secondo elemento è la condizione di esposizione. Le CVE sono sfruttabili solo se la funzione è attiva, e tre funzioni su quattro (NX-API, MPLS OAM, SRv6) non sono comuni in configurazioni di base. NGOAM è invece tipica negli ambienti VXLAN EVPN, ormai diffusi nei data center moderni: chi ha costruito una fabric overlay negli ultimi anni ha una probabilità concreta di averlo abilitato. Il consiglio pratico è non ragionare per "modello" ma per "feature attive": un inventario fatto con show feature vale più di una lista di apparati.

Il terzo elemento è la raggiungibilità. Il vettore è l'indirizzo IP del dispositivo, cioè tipicamente l'interfaccia di management o le interfacce di routing. Se la rete di management è realmente isolata e filtrata, il rischio cala molto; se invece le interfacce di gestione sono raggiungibili da segmenti ampi o, peggio, da fornitori esterni, la superficie d'attacco è maggiore di quanto si immagini. In molti audit gli switch di core hanno ACL di management vecchie di anni.

Sul piano normativo, per i soggetti essenziali e importanti rientranti nel perimetro NIS2 (in Italia il D.Lgs. 138/2024) la gestione delle vulnerabilità e la sicurezza dell'infrastruttura di rete rientrano tra le misure di gestione del rischio che ACN si aspetta di vedere documentate. Un advisory critico su apparati di core network, con una decisione tracciata (patch, mitigazione, accettazione motivata del rischio con data), è esattamente il tipo di evidenza che un'ispezione o un audit chiederà. Se un'eventuale compromissione portasse a un incidente significativo, valgono le tempistiche NIS2: pre-notifica al CSIRT Italia entro 24 ore, notifica entro 72 ore, relazione finale entro un mese. Per le entità finanziarie si aggiunge il quadro DORA sulla gestione dei rischi ICT di terze parti e dei fornitori critici di rete. Se poi l'incidente coinvolgesse dati personali, resta l'obbligo GDPR di notifica al Garante entro 72 ore dalla scoperta della violazione.

Un'ultima considerazione, da consulente: queste cinque falle sono state trovate da Cisco stessa. È un buon segno sul processo di sicurezza del fornitore, ma significa anche che dopo la pubblicazione gli avvisi diventano materiale di analisi per i ricercatori e per gli attori malevoli, che confrontano le versioni per individuare la differenza tra codice vulnerabile e codice corretto. Su apparati di rete di questo tipo, il periodo tra advisory e primo exploit pubblico è spesso breve. Non c'è nulla che indichi sfruttamento oggi, ma pianificare l'intervento adesso costa molto meno che farlo sotto pressione.

Cosa fare subito

  • Inventario delle funzioni attive: su ogni Nexus 3000 e 9000 standalone, esegui show feature | include ngoam, show feature | include nxapi, show feature | include mpls_oam e, dove rilevante, show feature | include srv6, per sapere quali CVE ti riguardano davvero.
  • Disattiva ciò che non serve: se NGOAM, NX-API o MPLS OAM non sono usati in produzione, disabilitali (no feature ngoam, no feature mpls oam) dopo un test in laboratorio; eliminano il vettore d'attacco anche prima della patch.
  • Pianifica l'aggiornamento: usa il Cisco Software Checker per la release corretta in base alla tua versione e inserisci l'intervento in una finestra di manutenzione ravvicinata, con piano di rollback.
  • Usa i Live Protect shield come ponte: dove non puoi riavviare subito, applica le protezioni temporanee di Cisco, senza considerarle un sostituto della patch.
  • Restringi l'accesso al piano di gestione: limita con ACL gli indirizzi che possono raggiungere gli IP degli switch (management, SSH, HTTP/NX-API) alle sole reti di amministrazione.
  • Controlla Cisco License: verifica se usi Smart Software Manager On-Prem o Cisco License; se la tua versione è precedente, pianifica la migrazione alla release corretta, perché per quelle vecchie non arriveranno patch.
  • Documenta la decisione: registra data, perimetro, scelta (patch, mitigazione, rischio accettato) e responsabile; sarà utile per NIS2, DORA e per eventuali audit.
  • Monitora i log: cerca riavvii anomali o crash dei processi sugli switch interessati nelle ultime settimane, perché un tentativo di sfruttamento fallito può lasciare proprio questo tipo di traccia.