Cisco NX-OS: falle critiche nei Nexus 3000 e 9000, e non solo

📌 Sviluppi successivi: Cisco: RCE critica in Expressway e falle in Unified CM e Snort 3 (21 ottobre 2026) · Cisco NX-API (CVE-2026-76471): colpiti anche gli UCS 6300 (13 ottobre 2026)

Il 7 ottobre 2026 Cisco ha pubblicato un nuovo gruppo di bollettini di sicurezza. Secondo SecurityWeek le correzioni riguardano 35 vulnerabilità, più di una decina delle quali critiche, tra NX-OS, Cisco License, APIC, Meraki e Finesse. Il caso più rilevante per i data center riguarda gli switch Nexus 3000 e 9000: BleepingComputer riporta cinque vulnerabilità critiche che, in certe configurazioni, permettono di eseguire codice come root sullo switch.

La notizia è riportata da due testate, BleepingComputer e SecurityWeek: di seguito ogni informazione è attribuita alla fonte. Nessuna delle due indica i punteggi CVSS delle falle di NX-OS, da leggere nei bollettini di Cisco. Secondo entrambe, Cisco non era a conoscenza di sfruttamenti; per BleepingComputer le falle di NX-OS sono emerse da test interni.

NX-OS: cinque falle critiche nei Nexus 3000 e 9000

Secondo BleepingComputer, le cinque vulnerabilità nascono da una validazione insufficiente dei dati ricevuti e colpiscono i Nexus 3000 e 9000 in modalità NX-OS standalone, solo se è attiva almeno una di tre funzioni: NX-API, Next Generation OAM (NGOAM) o MPLS OAM. Se l’esecuzione di codice non riesce, l’attaccante può comunque far cadere dei processi e provocare il riavvio dello switch.

• CVE-2026-76471: richiesta HTTP costruita ad arte verso NX-API, disattivata per impostazione predefinita.
• CVE-2026-76485, CVE-2026-76486 e CVE-2026-76501: pacchetti costruiti ad arte verso un’interfaccia IP, con NGOAM attivo. La CVE-2026-76486 richiede anche SRv6 oppure NV Overlay (un VNI VXLAN EVPN associato a un’interfaccia NVE, con almeno un VTEP remoto appreso); la CVE-2026-76501 richiede SRv6, supportato solo da alcuni Nexus 9000.
• CVE-2026-76465: richieste MPLS echo-request costruite ad arte verso un indirizzo IP dello switch. MPLS OAM è disattivato per impostazione predefinita; i Nexus 9000 con ASIC Silicon One non lo supportano e non sono colpiti.

Non sono colpiti i Nexus 7000 e i Nexus 9000 in modalità ACI.

SecurityWeek precisa che la CVE-2026-76471 e la CVE-2026-76465 sono sfruttabili da remoto e senza autenticazione. Sul numero di falle le fonti divergono: per BleepingComputer quelle critiche di NX-OS sono cinque, mentre per SecurityWeek NX-OS ha ricevuto 14 correzioni, sette critiche, con in più la CVE-2026-76455 e la CVE-2026-76459, che raggruppano difetti di controllo degli accessi e di scrittura fuori dai limiti della memoria. Queste due CVE sono citate solo da SecurityWeek.

In termini MITRE ATT&CK lo sfruttamento rientra in T1190 (Exploit Public-Facing Application) e, per il riavvio forzato, in T1499.004 (Endpoint Denial of Service: Application or System Exploitation). Le fonti non riportano indicatori di compromissione.

Cisco License, APIC, Meraki e Finesse

• Cisco License (in precedenza Smart Software Manager). BleepingComputer cita CVE-2026-76480 (funzione critica senza autenticazione, CVSS 9.8), CVE-2026-76482 (verifica errata della firma crittografica, CVSS 10.0), CVE-2026-76483 (credenziali protette male, CVSS 9.1) e CVE-2026-76484 (iniezione di codice, CVSS 8.8): versioni vulnerabili con qualsiasi configurazione, nessun workaround, correzione nella 10-202609; le vecchie versioni Smart Software Manager non saranno corrette e vanno migrate. SecurityWeek parla di License On-Prem, con cinque CVE critiche: le prime tre più la CVE-2026-20328 (accesso non autorizzato) e la CVE-2026-76454 (denial of service), sfruttabili senza autenticazione. La CVE-2026-76484 compare solo in BleepingComputer, le altre due solo in SecurityWeek.
• APIC, secondo SecurityWeek: tre CVE critiche (CVE-2026-76498, -76499 e -76500) per controllo degli accessi, iniezione di comandi del sistema operativo e memoria.
• Meraki, secondo SecurityWeek: una release di hardening con sette CVE; la più grave, CVE-2026-76464, copre buffer overflow e scritture fuori dai limiti.
• Finesse, secondo SecurityWeek: una SSRF di gravità alta già divulgata, CVE-2026-20362.

Impatto per le aziende europee e italiane

I Nexus 3000 e 9000 si trovano nei data center di aziende, fornitori di cloud e hosting e operatori di telecomunicazioni. Le condizioni descritte, come NGOAM con SRv6 o con NV Overlay su VXLAN EVPN, sono tipiche delle fabric di data center e delle reti dei fornitori: è lì che conviene controllare per primi. Uno switch preso con privilegi di root, o riavviato a ripetizione, può fermare un intero segmento del data center.

Per i soggetti NIS2, soprattutto nelle infrastrutture digitali e nei servizi gestiti, il caso rientra nella gestione delle vulnerabilità con priorità e tempi documentati; un’interruzione significativa dovuta a un attacco va valutata ai fini della notifica allo CSIRT Italia dell’ACN. Nella sanità, il riavvio di uno switch di core rende irraggiungibili le applicazioni cliniche.

Cosa fare subito

1. Fai l’inventario dei Nexus 3000 e 9000, con release di NX-OS (show version) e modalità (standalone o ACI).
2. Verifica le funzioni attive con show running-config | include feature: cerca NX-API, NGOAM, MPLS OAM, NV Overlay e SRv6.
3. Disattiva NX-API, NGOAM e MPLS OAM dove non servono: è la raccomandazione di Cisco riportata da BleepingComputer.
4. Aggiorna NX-OS alla release indicata da Cisco Software Checker, partendo dagli switch con NX-API raggiungibile e dalle fabric con NGOAM. Se non puoi riavviare subito, secondo BleepingComputer Cisco offre protezioni temporanee Live Protect per tutte e cinque le falle.
5. Limita l’accesso alle interfacce di gestione, a cominciare da NX-API, con una rete di gestione separata e liste di accesso: buona pratica generale, non sostituisce l’aggiornamento.
6. Sorveglia riavvii inattesi, crash di processi e richieste HTTP anomale verso NX-API, inviando i log degli switch a un sistema esterno.
7. Aggiorna Cisco License alla 10-202609, pianifica la migrazione delle vecchie installazioni e controlla nei bollettini di Cisco APIC, Meraki e Finesse.

Come aiuta ARXDOME

ARX Sentry raccoglie i log di firewall e dispositivi di rete in un collettore centrale: riavvii inattesi e crash di processi restano registrati fuori dallo switch e sono più facili da ricostruire. ARX Expose mostra quali servizi la tua azienda espone su Internet e quali hanno vulnerabilità note, così puoi verificare che un’interfaccia di gestione come NX-API non sia raggiungibile da fuori.

Ultimo aggiornamento: 8 ottobre 2026