On 7 October 2026 Cisco published advisory cisco-sa-napi-rce-r2shwu2j for CVE-2026-76471, a heap-based buffer overflow in the NX-API feature of Cisco NX-OS. An unauthenticated, remote attacker can send a crafted HTTP request to NX-API and execute arbitrary code with root privileges, or crash processes and reload the device. Cisco scores it CVSS 9.8, Critical.
Cisco found the bug during internal security testing and says its PSIRT is not aware of public announcements or malicious use. The advisory was revised on 8 October to update the fixed release table, so if you read it on day one, read it again.
What's affected
Devices are affected only if they run a vulnerable release and have NX-API enabled:
- Nexus 3000 Series Switches (bug ID CSCwu46199)
- Nexus 9000 Series Switches in standalone NX-OS mode (CSCwu46199)
- UCS 6300 Series Fabric Interconnects (CSCwu58579). Here exploitation requires valid low privilege credentials and goes through the UCS Manager XML API, so Cisco lowers the rating to High for this platform.
Cisco confirms these are not affected: Nexus 7000, Nexus 9000 in ACI mode, MDS 9000, UCS 6400, 6500 and 6600 Fabric Interconnects, UCS X-Series Direct Fabric Interconnect 9108 100G, Firepower 1000, 2100, 4100 and 9300, and Secure Firewall 200, 1200, 3100, 4200 and 6100.
For fixed software, the advisory points NX-OS customers to the Cisco Software Checker for the first fixed release for their train. For UCS 6300 Fabric Interconnects, release 4.3 is fixed in 4.3(6j), and release 4.2 and earlier must migrate to a fixed release.
There are no workarounds. Cisco has released a Live Protect shield for CVE-2026-76471 on NX-OS as a temporary mitigation, and says shields only bridge the gap until you can upgrade.
How to check if you're exposed
NX-API is disabled by default on Nexus 3000 and 9000 switches, according to the advisory. In practice it is often turned on by automation: configuration management tools, controllers and scripts that talk to switches over HTTP. Check each switch:
switch# show feature | include nxapi
nxapi 1 enabled
To sweep a fleet, run the same command through whatever you already use for inventory, or grep your configuration backups for the feature line:
# Saved running-configs from your backup system
grep -l "^feature nxapi" /srv/netbackups/nexus/*.cfg
For each switch with NX-API enabled, note the NX-OS release (show version) and run it through the Cisco Software Checker against this advisory. Also record which networks can reach the NX-API listener. Cisco's NX-API documentation gives HTTP port 80 and HTTPS port 443 as the defaults once the feature is enabled, so management ACLs and firewall rules matter here.
What to do now
- Upgrade affected Nexus 3000 and 9000 switches to the first fixed release the Software Checker reports for your train, and UCS 6300 Fabric Interconnects to 4.3(6j) or a later fixed release.
- Disable NX-API where nothing uses it. It is off by default, so any switch where it is on should have a known owner and a reason. If no tool depends on it, remove the feature. Cisco's NX-API documentation also gives
no nxapi httpandno nxapi httpsfor turning off individual listeners, which is useful when tools only use one of them. - Restrict reachability of NX-API to the automation hosts that need it, using management VRFs, ACLs and firewall rules. The bug is pre-authentication, so a strong password does not help.
- Apply the Live Protect shield where upgrades must wait for a change window, and track the upgrade as the real fix.
- Update your automation inventory. Each tool that needs NX-API should be listed with the switches it talks to. That list is what lets you turn the feature off everywhere else.
Why it matters
Network automation moved switch management from SSH sessions to HTTP APIs, and with it came the usual web attack surface: request parsers, buffers and authentication code that runs before any login. A management API that is reachable from a broad internal network turns one parsing bug into root on the switch.
The default-off detail is the useful part. Cisco ships NX-API disabled, so every enabled instance was a decision someone made, usually for a tool or a project. Platform teams that treat "feature nxapi" like any other exposed service, with an owner, an allowlist of clients and a patch SLA, will find this advisory much easier to close.
Try it yourself
Pull the last saved configuration for every Nexus switch you manage and count how many contain feature nxapi. For each one, name the tool that needs it. Any switch without an answer is a candidate for turning the feature off today.
Click through it at your own pace, or open it full screen.
Quick check
Is a Nexus 9000 switch in ACI mode affected by CVE-2026-76471?
No. Cisco lists Nexus 9000 Series Fabric Switches in ACI mode as not vulnerable. Nexus 9000 switches in standalone NX-OS mode are affected if NX-API is enabled.
How do you check whether NX-API is enabled?
Run show feature | include nxapi on the switch. An enabled line means the device is exposed if it also runs a vulnerable release.
Are there workarounds?
No. Cisco offers a Live Protect shield as a temporary mitigation on NX-OS, but upgrading is the remediation.
