Two sets of Cisco notices land on anyone running Nexus 3000 or Nexus 9000 switches in standalone NX-OS mode, and one of them also reaches the Nexus 7000. The first is the NX-OS bundle Cisco published on 2026 October 7: three Critical remote code execution advisories plus a hardening release with new fixed releases. The second is Cisco's notice on the broken eMudhra certificate authority, last updated 2026 November 4, which puts several NX-OS release trains under investigation. Here is what each one says, how to check a switch, and what to plan.
The three Critical advisories
Each of the three lets "an unauthenticated, remote attacker to execute arbitrary code with root privileges or cause a denial of service (DoS) condition". Each also depends on a feature you may not run, which is the first thing to check.
| Advisory | CVE | Base score | Feature that must be on |
|---|---|---|---|
| MPLS OAM | CVE-2026-76465 | 9.8 | MPLS OAM |
| NGOAM | CVE-2026-76485 and two more | 9.8 | NGOAM |
| NX-API | CVE-2026-76471 | 9.8 | NX-API |
To see whether a feature is on, Cisco gives "show feature | include mpls_oam" and "show feature | include ngoam" at the NX-OS command line.
On defaults, Cisco says: "The MPLS OAM feature is disabled by default on Cisco Nexus 3000 and 9000 Series Switches." and "The NX-API feature is disabled by default for Cisco Nexus 3000 and 9000 Series Switches." For NGOAM the bar is low once it is on: "To be affected by this vulnerability, the switch must have NGOAM enabled. That is the only requirement." Two of the NGOAM flaws need SRv6 or an NV Overlay as well, and Cisco notes that "Cisco Nexus 3000 Series switches do not support SRv6".
For MPLS OAM and NGOAM, Cisco says that if the feature is not required, disabling it "removes the attack vector and is a mitigation". The commands are "no feature mpls oam" and "no feature ngoam" in global configuration mode. NX-API has no such step in its advisory; Cisco offers a Live Protect shield "to temporarily mitigate this vulnerability" until you upgrade. None of the three has been seen in the wild: the PSIRT "is not aware of any public announcements or malicious use".
The hardening release, and the fixed trains
The hardening release is the one you cannot switch off. It groups flaws Cisco found internally and says they affect products "running a vulnerable release of Cisco NX-OS Software, regardless of device configuration", including Nexus 3000, Nexus 7000 and Nexus 9000 in both modes. The highest scores in its table are 9.8. Cisco adds that these "were found during internal testing and are not known to be actively exploited."
Its fixed releases are the ones to plan around:
| Platform | Release you run | First fixed release |
|---|---|---|
| Nexus 3000 and Nexus 9000, standalone NX-OS | 10.3 and earlier | 10.3(10) |
| Nexus 3000 and Nexus 9000, standalone NX-OS | 10.4 | 10.4(8) |
| Nexus 3000 and Nexus 9000, standalone NX-OS | 10.5 | 10.5(6) |
| Nexus 3000 and Nexus 9000, standalone NX-OS | 10.6 | 10.6(4) |
| Nexus 7000 | 8.3 and earlier | Migrate to a fixed release |
| Nexus 7000 | 8.4 | 8.4(14) |
A fourth notice in the same bundle, a Medium rated control plane advisory, also covers Nexus 3000, Nexus 7000 and Nexus 9000 "regardless of device configuration". It is a flood of "UDP or TCP connections to a data plane interface", not a takeover, and Cisco says the condition "will clear without manual intervention soon after the high rate of traffic is stopped."
The eMudhra certificate notice
The newer item is Cisco's eMudhra informational. A flaw in how eMudhra made its keys means, in Cisco's words, "Anyone in possession of these weak private keys can issue fraudulent TLS/HTTPS certificates for any domain on the internet." Cisco says the issue "impacts any Cisco product that trusts these compromised eMudhra intermediate certificates", so a device that trusts them can be fooled by a forged certificate.
For NX-OS, Cisco lists these under products still under investigation:
- Nexus 3000: "Releases 9.3(9) through 9.3(18) are impacted. Code train 10.x impacted except for train 10.1."
- Nexus 9000 in standalone NX-OS: "Releases 9.3(9) through 9.3(18) impacted. Code train 10.x impacted except for train 10.1."
- Nexus 9000 in ACI mode: "Code trains 15.x and 16.x are impacted."
The Nexus 7000 is on Cisco's list of products confirmed not affected, and so is Nexus Dashboard. There is no fixed NX-OS release in the notice yet; Cisco says "This advisory will be updated as additional information becomes available."
What to do on a switch you run
- Run the feature checks above. If MPLS OAM or NGOAM is on and you do not need it, Cisco's mitigation is to turn it off; for NX-API, plan the upgrade.
- Find your train and plan the move to its first fixed release from the hardening table. Before you plan a jump to another train, confirm in Cisco's release notes that your exact model runs it.
- Keep the eMudhra notice open. Nexus 3000 and Nexus 9000 trains are named, and Cisco will add fixes there.
- Use the Cisco Software Checker the advisories link to; it reports "the earliest release that fixes all the vulnerabilities" across advisories for a release you enter.
If you are buying Nexus now
Plan the software level before the switch arrives, so it goes into service on a fixed release. We have a Nexus 9000 switch, a second Nexus 9000 model, a Nexus 3000 and a Nexus 7000 chassis in stock, with the rest on the Nexus 9000 and Nexus 3000 shelves and the full Nexus range.
When you ask for a quote, tell us the release you need. For the end of life dates on these models see our earlier post, and the Cisco guide for the line as a whole.