Cisco NX-API flaw exposes switch management to root execution

An enabled management API on certain Cisco Nexus switches gives a remote attacker a path to root code execution without signing in. Cisco’s October 7 advisory, revised October 8, also covers UCS 6300 fabric interconnects, where the same vulnerability runs through an enabled-by-default XML API and requires valid low-privilege credentials. That difference changes which devices need an exposure check first.

The flaw is CVE-2026-76471, rated 9.8 under CVSS 3.1 for the unauthenticated path. A successful request can run code as root or crash processes and reload a device. For a data-center switch, a reload is a service interruption as well as a sign of possible device compromise. Cisco assigns the UCS 6300 case a High security impact rating because of its credential requirement.

HTTP input reaches NX-API

Cisco attributes the flaw to insufficient validation of data sent to NX-API. It says a crafted HTTP request to an affected device can reach the vulnerable feature. The Cisco CNA record classifies the weakness as CWE-122, a heap-based buffer overflow. Cisco describes the outcome directly: “execute arbitrary code with root privileges” or cause a denial-of-service condition. The issue was found during internal security testing.

On Nexus, an attacker who can reach enabled NX-API over HTTP on a vulnerable release can attempt root execution without an account. Cisco PSIRT reports no known public announcement or malicious use of this vulnerability. Check reachability from networks outside your trusted administration paths first.

Nexus and UCS take different paths

On Nexus 3000 and Nexus 9000 switches running standalone NX-OS, NX-API is disabled by default. From the NX-OS CLI, run show feature | include nxapi; Cisco’s enabled example reads nxapi 1 enabled. Pair that state with the installed NX-OS release and the management-interface access rules. Restrict HTTP reachability to trusted administration paths while you schedule the fixed release.

UCS 6300 fabric interconnects use the Cisco UCS Manager XML API for this flaw. That API is enabled by default, and Cisco says disabling it would break functionality. Check access to the XML API and which accounts have low-privilege credentials; use the UCS fixed-release table to plan their upgrade. Cisco confirms that Nexus 9000 switches in ACI mode and UCS 6400, 6500 and 6600 fabric interconnects are outside the affected product list.

Match releases before the maintenance window

Cisco provides a temporary Live Protect shield for NX-OS, but says a fixed software release is the remedy and that no workaround addresses the vulnerability. Use its advisory’s Software Checker with the actual NX-OS platform and running release to obtain the applicable first fixed release. For UCS 6300 on the 4.3 branch, the first fixed release is 4.3(6j); systems on 4.2 or earlier need to migrate to a fixed release. Cisco updated that fixed-release table on October 8.

Confirm the device family, running release and API access path on your own management network. On Nexus, record show feature | include nxapi before and after the change and verify that the software now matches the fixed release returned by Cisco’s checker. On UCS 6300, verify the installed UCS Manager release is 4.3(6j) or an applicable fixed release after migration, then check that XML API access follows your intended administration policy.