If your organisation runs its own data center, there is a good chance the traffic between your servers, storage, and business applications passes through Cisco Nexus switches. Cisco has just disclosed five critical flaws in the software those switches run, and on an affected switch someone with no username or password can take complete control of the device, or knock it offline, by sending it a single specially crafted message over the network. Everything above the switch depends on it, so a takeover can mean applications going dark, an intruder quietly watching or redirecting sensitive traffic, and a hidden foothold on hardware that most security tools never look at. There are no reports of attacks yet and the fixes are already available, which makes this the cheapest moment to act; the cost goes up sharply once someone works out how to weaponise the patches.
The flaws, tracked as CVE-2026-76471, CVE-2026-76465, CVE-2026-76485, CVE-2026-76486, and CVE-2026-76501, each carry a CVSS score of 9.8 out of 10. They affect Cisco Nexus 3000 Series and Nexus 9000 Series switches running in standalone NX-OS mode, and one of them also reaches UCS 6300 Series Fabric Interconnects. Whether a given switch is exposed depends on which of three features is turned on: NX-API, Next Generation OAM (NGOAM), or MPLS OAM. The sections below cover what each flaw needs to be exploitable, how to check your switches in a few minutes, and what to do in what order.
Why this one matters
Data center switches sit at the bottom of everything. Every application, database, and storage request in the data center crosses them, which makes them both critical to availability and an ideal vantage point for an attacker. They are also among the least watched systems in most environments: endpoint detection agents do not run on them, their logs are often not collected with the same care as server logs, and they tend to be patched on long maintenance cycles because every upgrade means a reload.
All five flaws lead to the same place. A successful exploit runs attacker-supplied code with root privileges on the switch, the highest level of control the device offers. From there an attacker can persist below the visibility of most security tooling, copy or redirect traffic, alter forwarding behaviour, and use the switch as a launching point into connected network segments. If the exploit is less precise, the vulnerable process crashes and the switch reloads, which is an outage in its own right and one that can be repeated on demand.
None of the five requires authentication on Nexus switches. Each is triggered by traffic sent to the switch over the network: an HTTP request to NX-API, a crafted packet to any IP interface for NGOAM, or a crafted MPLS echo-request for MPLS OAM. That is the profile of vulnerability most likely to be turned into a working exploit once researchers and attackers start comparing patched and unpatched code.
How this came to light
Cisco published three advisories on October 7, 2026 at 16:00 GMT as part of its scheduled NX-OS security release:
- cisco-sa-napi-rce-r2shwu2j covers CVE-2026-76471 in NX-API (bug IDs CSCwu46199 and CSCwu58579). Cisco updated it on October 8 to revise the fixed release table.
- cisco-sa-ngoam-rce-LWKQ4BU covers CVE-2026-76485, CVE-2026-76486, and CVE-2026-76501 in NGOAM (bug IDs CSCwu19785, CSCwu19823, and CSCwu57455).
- cisco-sa-moam-rce-uBTzYV7 covers CVE-2026-76465 in MPLS OAM (bug ID CSCwu19799).
Cisco found all five during internal security testing, and its Product Security Incident Response Team (PSIRT) says it is not aware of any public announcement or malicious use of them. There is no CISA Known Exploited Vulnerabilities listing for any of the five at the time of writing.
That is the good news, and it is worth taking at face value. It is also a temporary state of affairs. Network infrastructure has been a favoured target for state-sponsored groups for years, and Nexus switches specifically have been exploited before. In 2024, a China-linked group tracked as Velvet Ant used an NX-OS zero-day (CVE-2024-20399) to plant custom malware directly on Nexus switches and use them as a hiding place inside victim networks. That flaw required valid administrator credentials to exploit. The five disclosed this week do not.
How the flaws work
All five come down to the switch trusting input it receives over the network without properly checking it first. The specifics differ by feature.
NX-API (CVE-2026-76471)
NX-API is the programmatic interface that lets automation tools and scripts configure a Nexus switch over HTTP or HTTPS. The flaw is a heap-based buffer overflow (CWE-122) caused by insufficient validation of data sent to the API; a crafted HTTP request is enough to trigger it.
NX-API is disabled by default on Nexus 3000 and 9000 switches, but it is a staple of modern network automation and is routinely enabled in environments managed with Ansible, Terraform, or in-house tooling.
On UCS 6300 Series Fabric Interconnects the same flaw is reached through the UCS Manager XML API, which is enabled by default and cannot be disabled without losing functionality. Exploitation there requires valid low-privileged credentials, so Cisco rates the impact on UCS 6300 as High rather than Critical.
NGOAM (CVE-2026-76485, CVE-2026-76486, CVE-2026-76501)
Next Generation OAM provides operations, administration, and maintenance tooling for VXLAN and SRv6 fabrics, including loop detection, ping, and path tracing. All three flaws are stack-based buffer overflows (CWE-121) caused by improper validation of IP traffic when NGOAM is enabled; an attacker triggers them by sending crafted packets to an IP interface on the switch. The conditions for each are different:
| CVE | What must be enabled |
|---|---|
| CVE-2026-76485 | NGOAM. That is the only requirement. |
| CVE-2026-76486 | NGOAM, plus either SRv6 or NV Overlay. For NV Overlay, a VXLAN EVPN VNI must also be mapped to an NVE interface with at least one peer VTEP learned, for example through BGP EVPN or a static ingress-replication peer. |
| CVE-2026-76501 | NGOAM and SRv6. Nexus 3000 switches do not support SRv6, and only some Nexus 9000 models do. |
CVE-2026-76485 is the one to prioritise. Any Nexus 3000 or standalone Nexus 9000 switch with NGOAM turned on is exposed, with no other configuration prerequisites. VXLAN EVPN fabrics commonly enable NGOAM for troubleshooting, so this is likely to be more widespread than the "disabled by default" features suggest.
MPLS OAM (CVE-2026-76465)
MPLS OAM provides MPLS ping and traceroute for diagnosing label-switched paths. The flaw is an invalid memory free (CWE-590) triggered when the switch processes a crafted MPLS echo-request sent to one of its IP addresses.
MPLS OAM is disabled by default. Nexus 9000 switches built on Cisco Silicon One ASICs cannot run the feature at all and are not affected.
Who is affected
| Platform | Affected? | Condition |
|---|---|---|
| Nexus 3000 Series | Yes | NX-API, NGOAM, or MPLS OAM enabled (SRv6 not supported, so CVE-2026-76501 does not apply) |
| Nexus 9000 Series, standalone NX-OS mode | Yes | NX-API, NGOAM, or MPLS OAM enabled; Silicon One models are immune to the MPLS OAM flaw |
| UCS 6300 Series Fabric Interconnects | Yes, NX-API flaw only | Requires low-privileged credentials; rated High |
| Nexus 9000 Series, ACI mode | No | |
| Nexus 7000 Series | No | |
| MDS 9000 Series | No | |
| UCS 6400, 6500, 6600 Series and X-Series Direct 9108 | No | |
| Firepower and Secure Firewall appliances | No |
For UCS 6300 Fabric Interconnects, the first fixed release is 4.3(6j); anything on 4.2 or earlier needs to migrate to a fixed release. For Nexus switches, Cisco has not published a static table; instead, enter your NX-OS release into the Cisco Software Checker, which returns the first fixed release for each advisory and a "Combined First Fixed" release that addresses every advisory affecting your version.
What you should do
1. Find out which switches are exposed
Run these commands from the NX-OS CLI on every Nexus 3000 and standalone Nexus 9000 switch. Any feature that returns enabled on an unpatched release means the switch is exposed to the matching CVEs.
switch# show feature | include nxapi
switch# show feature | include ngoam
switch# show feature | include mpls_oam
switch# show feature | include srv6
switch# show feature | include nve
If NGOAM and NV Overlay are both enabled, run the following three commands as well. If all three return data, the switch meets the NV Overlay condition for CVE-2026-76486.
switch# show running-config | begin "interface nve"
switch# show nve vni
switch# show nve peers
Prioritise anything with NGOAM enabled, then anything with NX-API reachable from outside a tightly controlled management network.
2. Upgrade to a fixed release
This is the only full remediation, and there are no workarounds. Use the Software Checker to pick a target release, ideally the Combined First Fixed release so you are not back in a maintenance window next month, and schedule the reloads. Cisco also published a broader NX-OS security hardening release this month, so check whether other advisories apply to your version while you are there.
3. Turn off what you do not use
Disabling an unneeded feature removes the attack vector entirely and is the fastest meaningful step you can take today:
- NGOAM:
no feature ngoamin global configuration mode mitigates all three NGOAM flaws. - MPLS OAM:
no feature mpls oammitigates CVE-2026-76465. - NX-API: if no automation tooling depends on it, disable it.
Cisco cautions that these changes should be evaluated in your own environment first, since disabling a feature that is in active use can affect how the network operates.
4. Use Live Protect shields where upgrades must wait
Cisco has released Live Protect shields for all five CVEs. These are temporary mitigations for NX-OS that can be applied to switches that cannot yet be upgraded and reloaded. They are a bridge, not a fix; Cisco is explicit that the upgrade is still required.
5. Restrict who can reach the vulnerable code
Even before patching, narrow the attack surface. Limit NX-API access to a dedicated management network and approved automation hosts using ACLs and control-plane policing. Where your design allows it, filter MPLS echo-requests and OAM traffic arriving from untrusted sources at the fabric edge. None of this replaces the upgrade, but it shrinks the pool of people who could exploit the flaws in the meantime.
6. Watch for warning signs
Treat unexpected switch reloads, crashed NX-OS processes, or unusual requests to NX-API endpoints as possible exploitation attempts until shown otherwise, rather than as routine instability. Forward switch logs to a central collector an attacker cannot easily reach, so that you have something trustworthy to look at if the question ever comes up.
A note on the pattern
This is the second time in two weeks we have written about critical Cisco flaws in the infrastructure that sits underneath everything else, following the actively exploited SD-WAN Manager zero-day (CVE-2026-76504) at the start of October. The difference this time is that nobody is known to be exploiting these yet, and that difference is worth protecting.
Network devices tend to be patched last because they are hard to reboot, monitored least because they cannot run security agents, and trusted most because everything depends on them. Attackers know this, which is why switches, routers, and firewalls keep turning up as entry points and hiding places in serious intrusions. The organisations that fare best are the ones that treat core network gear as a crown jewel: features enabled only where needed, management interfaces kept off untrusted networks, logs sent somewhere safe, and an upgrade process fast enough to close a critical gap in weeks rather than quarters.
Summary
| CVEs | CVE-2026-76471, CVE-2026-76465, CVE-2026-76485, CVE-2026-76486, CVE-2026-76501 |
| Components | Cisco NX-OS NX-API, Next Generation OAM (NGOAM), and MPLS OAM |
| Types | Heap-based buffer overflow (CWE-122), stack-based buffer overflow (CWE-121), invalid memory free (CWE-590) |
| CVSS | 9.8 (Critical) for all five |
| Impact | Unauthenticated remote code execution as root, or denial of service through process crash and reload |
| Affected | Nexus 3000 and standalone Nexus 9000 switches with NX-API, NGOAM, or MPLS OAM enabled; UCS 6300 Fabric Interconnects for CVE-2026-76471 (authenticated, High) |
| Not affected | Nexus 9000 in ACI mode, Nexus 7000, MDS 9000, UCS 6400/6500/6600, Firepower and Secure Firewall |
| Disclosed | October 7, 2026 (cisco-sa-napi-rce-r2shwu2j, cisco-sa-ngoam-rce-LWKQ4BU, cisco-sa-moam-rce-uBTzYV7) |
| Exploited in the wild? | No known exploitation at time of disclosure |
| CISA KEV? | No |
| Workaround | None; disabling unused features removes the attack vector, and Live Protect shields are available as a temporary measure |
| Detection | show feature checks for nxapi, ngoam, mpls_oam, srv6, and nve; unexpected reloads or process crashes |
| Full fix | Upgrade NX-OS to the release given by the Cisco Software Checker; UCS 6300 to 4.3(6j) or later |
Five critical flaws, no authentication, no workarounds, and no exploitation yet: that combination is a rare head start, and it will not last. Check which features are enabled, switch off the ones you do not need, shield what you cannot upgrade this week, and get the fixed release scheduled.
If you need help mapping your Nexus exposure, validating mitigations across your fabric, or putting monitoring in place on network infrastructure that currently has none, get in touch. The switches your data center runs on deserve the same scrutiny as the servers they connect.