Cisco NX-API (CVE-2026-76471): colpiti anche gli UCS 6300

L’8 ottobre 2026 ARX News ha descritto le falle critiche corrette da Cisco in NX-OS, tra cui la CVE-2026-76471 in NX-API, segnalata allora per gli switch Nexus 3000 e 9000. Il 13 ottobre 2026 INCIBE-CERT, il CSIRT nazionale spagnolo, ha pubblicato un avviso dedicato a questa sola vulnerabilità (identificativo INCIBE-2026-731, importanza «5 - Crítica») che aggiunge un dettaglio rilevante: tra i prodotti colpiti ci sono anche i Cisco UCS 6300 Series Fabric Interconnects, con le relative versioni corrette.

Questo articolo si basa su una sola fonte, l’avviso di INCIBE-CERT: di seguito ogni informazione è attribuita a lei. L’avviso non riporta il punteggio CVSS né indicatori di compromissione; nella tabella delle CVE la voce «Explotación» è «No», cioè non risultano sfruttamenti.

La vulnerabilità in breve

Secondo INCIBE-CERT, la CVE-2026-76471 è un heap buffer overflow dovuto a una validazione insufficiente dei dati inviati a NX-API, l’interfaccia di programmazione di NX-OS raggiungibile via HTTP. Con una richiesta HTTP costruita ad arte un attaccante può:

• eseguire codice arbitrario con privilegi di root sul dispositivo;
• in alternativa, far cadere dei processi e provocare il riavvio del dispositivo, con un denial of service.

L’avviso descrive l’attaccante come remoto e non autenticato, con un’eccezione importante per gli UCS 6300 (vedi di seguito).

Prodotti colpiti: anche gli UCS 6300

INCIBE-CERT elenca le versioni vulnerabili di Cisco NX-OS su tre famiglie di prodotti:

• Nexus 3000 con la funzione NX-API attiva;
• Nexus 9000 in modalità NX-OS standalone, con NX-API attiva;
• UCS 6300 Series Fabric Interconnects.

Sui Nexus 3000 e 9000 NX-API è disattivata per impostazione predefinita: lo switch è esposto solo se qualcuno l’ha accesa, di solito per l’automazione o per strumenti di gestione. Sugli UCS 6300, invece, secondo INCIBE-CERT lo sfruttamento richiede credenziali valide, anche con privilegi bassi. L’avviso non dice se sugli UCS 6300 la funzione sia attiva di serie.

La differenza conta per le priorità: sui Nexus il rischio dipende dalla configurazione, sugli UCS 6300 dagli account che possono accedere al Fabric Interconnect. Nei sistemi UCS i Fabric Interconnect, di solito installati in coppia, sono il punto da cui passano la connettività e la gestione dei server del dominio: un riavvio forzato o una compromissione con privilegi di root hanno effetto su tutti i server collegati.

Versioni corrette e mitigazioni

Secondo INCIBE-CERT:

• NX-OS (Nexus 3000 e 9000): aggiornare alla prima release corretta per ogni piattaforma, indicata da Cisco Software Checker. L’avviso non elenca i numeri di versione.
• UCS 6300 Series Fabric Interconnects: con la release 4.2 o precedenti bisogna migrare a una release corretta; con la 4.3 bisogna aggiornare alla 4.3(6j) o successiva.
• Nessun workaround. Per NX-OS Cisco ha pubblicato uno shield Live Protect come mitigazione temporanea, ma raccomanda di installare l’aggiornamento.

Disattivare NX-API dove non serve, come indicato nell’articolo dell’8 ottobre, toglie sui Nexus la condizione richiesta dall’avviso, ma non è un workaround ufficiale e non sostituisce l’aggiornamento.

In termini MITRE ATT&CK lo sfruttamento rientra in T1190 (Exploit Public-Facing Application); sugli UCS 6300, dove servono credenziali, si aggiunge T1078 (Valid Accounts); il riavvio forzato rientra in T1499.004 (Endpoint Denial of Service: Application or System Exploitation).

Impatto per le aziende europee e italiane

Gli UCS 6300 si trovano nei data center di aziende, fornitori di servizi gestiti e pubbliche amministrazioni, spesso sotto i cluster di virtualizzazione. Il requisito delle credenziali riduce l’esposizione, ma non la annulla: basta un account a bassi privilegi, magari usato da uno strumento di monitoraggio o da un fornitore esterno, per arrivare a codice come root sul Fabric Interconnect. Chi ha ancora UCS 6300 con release 4.2 o precedenti non ha un aggiornamento puntuale e deve pianificare una migrazione.

Per i soggetti NIS2 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 blocco dei Fabric Interconnect fermerebbe i server delle applicazioni cliniche ospitate in quel dominio UCS.

Cosa fare subito

1. Fai l’inventario dei Fabric Interconnect UCS 6300 e della loro release, oltre ai Nexus 3000 e 9000 già censiti dopo l’avviso dell’8 ottobre.
2. Aggiorna gli UCS 6300 con release 4.3 alla 4.3(6j) o successiva; per la 4.2 e precedenti pianifica la migrazione a una release corretta.
3. Verifica NX-API sui Nexus con show feature | include nxapi e disattivala dove non serve; poi aggiorna NX-OS alla release indicata da Cisco Software Checker.
4. Rivedi gli account che accedono agli UCS 6300: togli quelli inutilizzati o condivisi, controlla quelli dei fornitori e degli strumenti di monitoraggio.
5. Limita l’accesso alle interfacce di gestione con una rete dedicata e liste di accesso: buona pratica generale, non sostituisce l’aggiornamento.
6. Usa Live Protect su NX-OS solo come ponte, se non puoi aggiornare subito.
7. Sorveglia riavvii inattesi, crash di processi e richieste HTTP anomale verso NX-API, inviando i log dei dispositivi a un sistema esterno.

Come aiuta ARXDOME

ARX Sentry raccoglie i log di firewall e dispositivi di rete in un collettore centrale: riavvii inattesi, crash e accessi alla gestione restano registrati fuori dal dispositivo, anche se questo viene riavviato. ARX Expose mostra quali servizi la tua azienda espone su Internet e quali hanno vulnerabilità note, così puoi verificare che nessuna interfaccia di gestione sia raggiungibile da fuori.

Ultimo aggiornamento: 13 ottobre 2026