Cisco has disclosed five critical vulnerabilities in NX-OS that could allow unauthenticated remote attackers to execute arbitrary code with root privileges on vulnerable Nexus switches. The flaws affect Cisco Nexus 3000 and Nexus 9000 Series devices running in standalone NX-OS mode and are tied to three different features: NX-API, Next Generation OAM, or NGOAM, and MPLS OAM. All five vulnerabilities carry a CVSS score of 9.8, and successful exploitation can either give an attacker root-level execution on the switch or crash affected processes and force the device to reload, producing a denial-of-service condition.

The vulnerabilities are CVE-2026-76471, CVE-2026-76485, CVE-2026-76486, CVE-2026-76501 and CVE-2026-76465. Although they reach similar outcomes, they do not all share the same exposure conditions. CVE-2026-76471 affects NX-API and can be triggered using a crafted HTTP request when NX-API is enabled. NX-API is disabled by default on Nexus 3000 and Nexus 9000 switches, which limits exposure, but environments that deliberately enable it for automation or software-defined network management need to treat the interface as a potentially remote root-level attack surface until patched.

The NX-API flaw is particularly significant because the exploitation chain is short: attacker reaches NX-API → sends crafted unauthenticated HTTP request → insufficient input validation triggers memory corruption → arbitrary code executes with root privileges. There is no requirement for a valid account, user interaction or an already compromised internal endpoint. If an exposed management API is reachable from an untrusted network and running a vulnerable release, the attacker may be able to move directly from network access to privileged code execution on the switch.

The other three vulnerabilities, CVE-2026-76485, CVE-2026-76486 and CVE-2026-76501, affect Cisco's Next Generation OAM functionality. Cisco says specially crafted IP traffic can trigger stack-based buffer overflows in the NGOAM implementation and allow an unauthenticated remote attacker to execute code as root or cause the device to crash. These flaws require NGOAM to be enabled, meaning configuration remains an important part of exposure assessment. CVE-2026-76486 also requires either SRv6 or an NV Overlay configuration, while CVE-2026-76501 depends on SRv6, which is available only on certain Nexus 9000 models.

CVE-2026-76465 affects MPLS OAM and results from improper validation while processing MPLS echo-request packets. An attacker able to send a crafted request to an affected device can similarly achieve root-level execution or cause a reload. MPLS OAM is disabled by default, and Nexus 9000 platforms using Silicon One ASICs do not support the vulnerable feature and therefore are not affected by this particular CVE. Cisco Nexus 7000 systems and Nexus 9000 switches running in ACI mode are also not affected by these five flaws.

That feature dependency is important because the headline “Cisco Nexus takeover” can make the issue sound as though every Nexus switch is immediately exploitable from the Internet. That is not the case. Administrators need to establish three things: is the device running an affected NX-OS version, is the relevant feature enabled, and can untrusted traffic reach the vulnerable interface or protocol? Exposure is determined by that combination, not merely by the product model.

The consequence of successful exploitation, however, is difficult to overstate. A data-center switch is not just another Linux host. It sits directly in the path of enterprise traffic and may carry communication between servers, storage platforms, hypervisors, security appliances and management systems. Root-level compromise of the device gives the attacker control over infrastructure that other systems implicitly trust.

Depending on configuration and attacker capability, control of a switch could potentially be used to alter routing or forwarding behavior, create or modify network paths, disrupt connectivity, assist lateral movement, observe traffic available to the device, interfere with segmentation, or provide a durable infrastructure foothold. Those are post-compromise possibilities rather than capabilities Cisco has documented as being actively used through these specific vulnerabilities, but they explain why root RCE on a core switch deserves much higher operational urgency than the same code-execution primitive on an ordinary application server.

The security boundary is especially important in modern data centers because Nexus switches frequently participate in automation and network orchestration. NX-API exists precisely so external management systems can programmatically interact with the device. Automation increases operational efficiency, but it also creates a powerful remotely accessible management surface. An API capable of configuring infrastructure becomes one of the most privileged interfaces in the environment.

This creates an architectural principle worth emphasizing: management APIs should never be exposed more broadly than the systems that genuinely require them. Even after CVE-2026-76471 is patched, organizations should examine whether NX-API is reachable from user VLANs, Internet-facing networks or broad internal segments. Management access should normally be confined to dedicated management networks, jump hosts, orchestration systems or other tightly controlled sources.

The NGOAM vulnerabilities illustrate a slightly different problem. Operational and diagnostic protocols are often enabled because they help network teams troubleshoot overlays, tunnels and reachability. They are rarely perceived as equivalent to administrative interfaces. Yet if malformed operational traffic can reach memory-unsafe code running at high privilege, a diagnostic protocol becomes a remote-code-execution surface.

That is a recurring weakness in infrastructure security. Features designed for management, telemetry, troubleshooting or control-plane operations often receive less scrutiny than obvious web interfaces even though they run inside the most trusted layer of the device.

The practical attack chain for these vulnerabilities can therefore take several forms:

reachable NX-API → crafted HTTP request → memory corruption → root RCE

or:

reachable NGOAM-enabled device → crafted IP packet → stack-based buffer overflow → root RCE

or:

MPLS OAM enabled → crafted MPLS echo request → improper memory handling → root RCE.

The packets differ, but the outcome is essentially the same: attacker-controlled input reaches a privileged network-service component that fails to validate it safely.

The alternative outcome is denial of service. If reliable code execution cannot be achieved, exploitation can crash affected processes and cause the switch to reload. On a data-center switch, that is not a minor availability event. Depending on redundancy and topology, a reload can interrupt large numbers of workloads, application paths or storage flows simultaneously.

Organizations should therefore think about these CVEs in terms of both security compromise and operational resilience. Even an unsuccessful exploitation attempt could still become a service-disruption mechanism.

Cisco has released fixed NX-OS versions and recommends that customers use its Software Checker to identify the appropriate patched release for their hardware and software branch. Cisco states that there are no complete workarounds for the vulnerabilities. However, if the affected features are unnecessary, disabling NX-API, NGOAM or MPLS OAM removes the corresponding attack surface. Cisco has also released Live Protect shields for the flaws as temporary protection for organizations that cannot immediately schedule an NX-OS upgrade and reboot.

The wording around Live Protect matters. Cisco treats these shields as temporary mitigation rather than remediation. They are useful for closing an exposure window while infrastructure teams work through maintenance requirements, but organizations should still move to a fixed release.

This is particularly important for switches because patching network infrastructure tends to happen more slowly than patching ordinary servers. Network devices often require maintenance windows, redundancy validation and coordination across multiple teams. Attackers know that, which means the period between advisory publication and full fleet remediation can be considerably longer than security teams would prefer.

Organizations should first inventory all Nexus 3000 and 9000 devices running standalone NX-OS, then identify which of the affected features are active. For NX-API, Cisco specifically recommends checking feature status using the NX-OS CLI. The same exposure review should be done for NGOAM, SRv6, NV Overlay and MPLS OAM according to the relevant advisory.

The next question should be reachability. An enabled vulnerable feature that is accessible only from a tightly controlled management network is less exposed than the same feature reachable from broad production networks. That does not remove the need to patch, but it materially changes immediate exploitation risk.

Network ACLs and control-plane policing can also help reduce the number of systems capable of sending traffic to management and diagnostic functions. Infrastructure protocols should not simply accept packets from everywhere because somebody may need them someday. That particular interpretation of flexibility has been keeping incident responders employed for decades.

Because Cisco says there is no evidence of exploitation at disclosure, this is also a good opportunity for organizations to get ahead of a likely exploitation cycle rather than waiting for proof-of-concept code or botnet scanning. All five vulnerabilities were found during Cisco's internal security testing, and Cisco PSIRT says it is not aware of public announcements or malicious use.

That fact should not be misinterpreted as indicating low urgency. Five unauthenticated, network-reachable 9.8 vulnerabilities that result in root execution on major data-center switching platforms are exactly the kind of flaws that become interesting once technical differences between patched and vulnerable releases are analyzed.

Attackers do not necessarily need Cisco to publish a proof of concept. Once patches are available, researchers can compare binaries, identify changed validation logic and reconstruct the vulnerable code path. The disclosure clock is therefore already running.

The flaws are also a reminder that network infrastructure should be included in vulnerability-management programs at the same level as operating systems and applications. In many organizations, server patching has automated inventory, severity-based SLAs and centralized reporting while network firmware remains a slower manually coordinated process. That gap becomes dangerous when a network operating system contains remotely exploitable root-level vulnerabilities.

Switches, routers, firewalls, load balancers and VPN gateways are effectively specialized servers controlling much more sensitive portions of the environment.

They should be managed accordingly.

Defenders should also monitor for unusual traffic directed at the vulnerable interfaces. For NX-API, that means unexpected HTTP requests to the API from systems that do not normally manage the switches. For NGOAM and MPLS OAM, abnormal packets originating from unexpected network segments deserve investigation. Switch process crashes or unexpected device reloads during the exposure window should also be treated as potentially security-relevant rather than automatically dismissed as stability problems.

That lesson has become increasingly important across infrastructure vulnerabilities: a crash can be exploit telemetry.

If a vulnerable parser receives attacker-controlled input, failed exploitation may manifest as a process failure long before defenders see successful code execution. Network operations and security teams therefore need to correlate unexplained NX-OS crashes with packet telemetry and security logs instead of investigating them in separate organizational silos.

The October Cisco advisory batch also contains other major security issues, but these five Nexus flaws deserve particular attention because they cross directly into the network control layer. Root access to a switching platform can create a very different blast radius from compromise of one ordinary workload.

The defensive sequence should therefore be:

identify affected Nexus devices → identify NX-API, NGOAM and MPLS OAM configuration → determine network reachability → disable unused features → deploy Live Protect where appropriate → upgrade NX-OS to a fixed release → review unexplained crashes and suspicious management/control-plane traffic → restrict management interfaces after remediation.

The final step matters because patching the immediate memory-safety flaw does not answer the architectural question of why a highly privileged management or diagnostic feature was reachable from an unnecessary network segment in the first place.

The broader lesson from these vulnerabilities is not simply that Cisco shipped five buffer-validation flaws.

It is that network infrastructure itself is an endpoint, except compromise can affect everything connected through it.

Organizations commonly design segmentation assuming the switch is the enforcement mechanism separating one trust zone from another.

Once the switch itself becomes attacker-controlled, that assumption deserves reconsideration.

Security architecture therefore needs to protect not only the traffic passing through the network, but the infrastructure deciding where that traffic is allowed to go.

A root shell on a server compromises a server.

A root shell on the device carrying the data-center network can potentially compromise the assumptions underneath many servers at once.

Cisco released security advisories for five critical vulnerabilities in its NX-OS data center network operating system that could be exploited to run arbitrary code with root privileges on Nexus switches. [...]

Source: Cisco warns of critical flaws allowing Nexus switch takeover via Bleeping Computer — published 08 Oct 2026.