Indice dell'articolo
Rischio e azione: Cisco ha pubblicato due vulnerabilità critiche in NX-OS che, in configurazioni specifiche, possono consentire a un attaccante remoto non autenticato di eseguire codice con privilegi root o provocare il riavvio del dispositivo. Le organizzazioni che gestiscono switch Nexus 3000 o 9000 devono verificare subito se sono attivi NX-API o MPLS OAM, identificare la release installata e pianificare l’aggiornamento indicato da Cisco.
Le due vulnerabilità
CVE-2026-76471, con punteggio CVSS 9.8, riguarda la validazione insufficiente dei dati inviati a NX-API. Una richiesta HTTP costruita ad arte può portare all’esecuzione di codice root o a crash di processo con reload del dispositivo. Sono interessati Nexus 3000 e Nexus 9000 in modalità NX-OS standalone quando NX-API è abilitata. La funzione è disattivata per impostazione predefinita su questi switch.
La stessa vulnerabilità interessa anche UCS 6300 Fabric Interconnect attraverso l’XML API di UCS Manager, ma in questo caso servono credenziali valide con privilegi bassi e Cisco riduce la classificazione a High. Nexus 9000 in modalità ACI, Nexus 7000, MDS 9000 e le generazioni UCS 6400, 6500 e 6600 sono elencate da Cisco tra i prodotti non vulnerabili a questa specifica falla.
CVE-2026-76465, anch’essa CVSS 9.8, colpisce l’elaborazione dei pacchetti MPLS echo-request nella funzione MPLS OAM. Il risultato possibile è ancora esecuzione di codice root o denial of service. Sono coinvolti Nexus 3000 e 9000 standalone con MPLS OAM attiva; la funzione è disabilitata di default e i Nexus 9000 con ASIC Silicon One non la supportano.
Come verificare l’esposizione
La presenza del modello nell’inventario non basta per dichiarare il rischio. Per NX-API eseguire dalla CLI NX-OS show feature | include nxapi; per MPLS OAM usare show feature | include mpls_oam. Un risultato enabled conferma il prerequisito funzionale, ma occorre poi confrontare piattaforma e versione con il Cisco Software Checker e con la sezione “Fixed Software” dell’advisory.
Non limitate la verifica all’indirizzo di gestione noto. Controllate ACL, management VRF, interfacce esposte, jump host, VPN amministrative e percorsi indiretti da reti server compromesse. Una funzione non pubblicata su Internet può comunque essere raggiungibile da segmenti interni non affidabili.
Mitigazione e patching
Per CVE-2026-76471 Cisco non indica workaround; ha reso disponibile un Live Protect shield temporaneo per alcuni ambienti, ma specifica che la correzione definitiva resta l’aggiornamento. Per CVE-2026-76465, se MPLS OAM non è necessaria, no feature mpls oam rimuove il vettore di attacco. La disattivazione va però testata rispetto a diagnostica MPLS, monitoraggio e procedure operative.
Cisco dichiara di non conoscere sfruttamento malevolo pubblico al momento della pubblicazione. Di conseguenza l’intervento ordinario è vulnerability management prioritario, non automaticamente incident response. Se i log mostrano richieste anomale verso NX-API, crash, reload inattesi o modifiche non autorizzate, preservate le evidenze e aprite il processo di risposta all’incidente: installare la patch non dimostra che il dispositivo fosse integro prima dell’aggiornamento.
Checklist operativa
- Inventariare Nexus 3000, Nexus 9000 standalone e UCS 6300, includendo versione e modalità operativa.
- Verificare lo stato di NX-API e MPLS OAM con i comandi ufficiali.
- Mappare la raggiungibilità reale delle interfacce di gestione e applicare restrizioni coerenti con il piano di controllo.
- Usare Cisco Software Checker per identificare la prima release corretta e una release combinata che copra gli altri advisory applicabili.
- Salvare configurazione, stato di ridondanza, immagini correnti e procedura di rollback prima della finestra.
- Testare la release su hardware o laboratorio equivalente, inclusi routing, vPC, telemetria e orchestrazione.
- Applicare l’aggiornamento secondo il piano di continuità; non trattare Live Protect come soluzione permanente.
- Dopo il riavvio, verificare versione, configurazione, adiacenze, traffico, ridondanza, logging e monitoraggio.
- Riesaminare log e crash precedenti alla patch; attivare incident response solo in presenza di indicatori concreti.
Devi verificare e aggiornare una rete Cisco senza interrompere i servizi? Richiedi una valutazione tecnica a MSP In Cloud.