Cisco NX-API flaw CVE-2026-76471 also hits UCS 6300

On 8 October 2026 ARX News covered the critical flaws Cisco fixed in NX-OS, including CVE-2026-76471 in NX-API, reported at the time for Nexus 3000 and 9000 switches. On 13 October 2026 INCIBE-CERT, Spain’s national CSIRT, published an advisory dedicated to this vulnerability alone (identifier INCIBE-2026-731, importance «5 - Crítica») that adds a relevant detail: the affected products also include Cisco UCS 6300 Series Fabric Interconnects, together with their fixed releases.

This article is based on a single source, the INCIBE-CERT advisory: every statement below is attributed to it. The advisory gives no CVSS score and no indicators of compromise; in its CVE table the «Explotación» field reads «No», meaning no exploitation has been reported.

The vulnerability in brief

According to INCIBE-CERT, CVE-2026-76471 is a heap buffer overflow caused by insufficient validation of data sent to NX-API, the NX-OS programming interface reachable over HTTP. With a crafted HTTP request an attacker can:

• execute arbitrary code with root privileges on the device;
• alternatively, crash processes and force a device reload, causing a denial of service.

The advisory describes the attacker as remote and unauthenticated, with an important exception for the UCS 6300 (see below).

Affected products: UCS 6300 too

INCIBE-CERT lists vulnerable Cisco NX-OS releases on three product families:

• Nexus 3000 with the NX-API feature enabled;
• Nexus 9000 in standalone NX-OS mode, with NX-API enabled;
• UCS 6300 Series Fabric Interconnects.

On Nexus 3000 and 9000, NX-API is disabled by default: a switch is exposed only if someone has turned it on, usually for automation or management tools. On the UCS 6300, by contrast, INCIBE-CERT says exploitation requires valid credentials, even low-privileged ones. The advisory does not say whether the feature is enabled by default on the UCS 6300.

The difference matters for priorities: on Nexus switches the risk depends on configuration, on the UCS 6300 on the accounts that can reach the Fabric Interconnect. In UCS systems, Fabric Interconnects, usually deployed in pairs, are where connectivity and management of the domain’s servers pass through: a forced reload or a root-level compromise affects every connected server.

Fixed releases and mitigations

According to INCIBE-CERT:

• NX-OS (Nexus 3000 and 9000): upgrade to the first fixed release for each platform, as indicated by Cisco Software Checker. The advisory does not list version numbers.
• UCS 6300 Series Fabric Interconnects: on release 4.2 or earlier you need to migrate to a fixed release; on 4.3 you need to upgrade to 4.3(6j) or later.
• No workarounds. For NX-OS, Cisco has published a Live Protect shield as a temporary mitigation, but recommends installing the fixed software.

Disabling NX-API where it is not needed, as noted in the 8 October article, removes on Nexus switches the condition the advisory requires, but it is not an official workaround and does not replace the upgrade.

In MITRE ATT&CK terms, exploitation falls under T1190 (Exploit Public-Facing Application); on the UCS 6300, where credentials are needed, T1078 (Valid Accounts) also applies; the forced reload falls under T1499.004 (Endpoint Denial of Service: Application or System Exploitation).

Impact for European and Italian organisations

UCS 6300 systems are found in the data centres of companies, managed service providers and public administrations, often underneath virtualisation clusters. The credential requirement reduces exposure but does not remove it: a single low-privileged account, perhaps used by a monitoring tool or an external supplier, is enough to reach root code execution on the Fabric Interconnect. Anyone still running UCS 6300 on release 4.2 or earlier has no in-place fix and must plan a migration.

For NIS2 entities this falls under vulnerability management with documented priorities and timelines; a significant disruption caused by an attack must be assessed for notification to the national CSIRT (in Italy, CSIRT Italia at ACN). In healthcare, a Fabric Interconnect outage would stop the servers running the clinical applications hosted in that UCS domain.

What to do now

1. Inventory your UCS 6300 Fabric Interconnects and their releases, alongside the Nexus 3000 and 9000 switches already reviewed after the 8 October advisory.
2. Upgrade UCS 6300 systems on release 4.3 to 4.3(6j) or later; for 4.2 and earlier, plan the migration to a fixed release.
3. Check NX-API on Nexus switches with show feature | include nxapi and disable it where not needed; then upgrade NX-OS to the release indicated by Cisco Software Checker.
4. Review the accounts that can access the UCS 6300: remove unused or shared ones, and check those of suppliers and monitoring tools.
5. Restrict access to management interfaces with a dedicated network and access lists: good general practice, not a substitute for the upgrade.
6. Use Live Protect on NX-OS only as a bridge if you cannot upgrade right away.
7. Watch for unexpected reloads, process crashes and anomalous HTTP requests to NX-API, forwarding device logs to an external system.

How ARXDOME helps

ARX Sentry collects firewall and network device logs in a central collector: unexpected reloads, crashes and management logins stay recorded outside the device, even if it reboots. ARX Expose shows which services your organisation exposes on the Internet and which have known vulnerabilities, so you can check that no management interface is reachable from outside.

Last updated: 13 October 2026