Cisco NGOAM flaws expose Nexus switches to root code execution

On a Cisco Nexus 3000 or standalone NX-OS Nexus 9000 switch, enabling NGOAM alone is enough to expose one of three critical packet-processing flaws. Cisco’s October 7 advisory says crafted traffic sent to an IP interface on an affected switch could run code as root, crash a process, or reload the device. The attacker needs no credentials.

Two other flaws depend on additional routing or overlay features. That makes a switch’s running configuration as important as its software release when deciding which of the three flaws applies. Cisco found them during internal security testing; its PSIRT says it is unaware of public announcements or malicious use.

Packets reach enabled NGOAM

NGOAM handles operational diagnostics for VXLAN and Segment Routing over IPv6 (SRv6). Cisco attributes the flaws to improper validation of IP traffic while that feature is enabled. Its CNA records classify the first, the second, and the third as stack-based buffer overflows (CWE-121).

Cisco describes the consequence plainly: “execute arbitrary code with root privileges.” A process crash can also reload a switch and interrupt traffic through it. All three records carry a CVSS 9.8 base score. The score describes severity under the affected configuration, while Cisco’s feature tests tell you which devices need work.

Feature combinations change exposure

For CVE-2026-76485, NGOAM enabled is the only feature requirement. CVE-2026-76486 also needs SRv6 or NV Overlay. On the NV Overlay branch, Cisco specifies a VXLAN EVPN VNI mapped to an NVE interface with at least one learned peer VTEP. CVE-2026-76501 needs NGOAM and SRv6. Nexus 3000 switches lack SRv6 support, and only some Nexus 9000 switches support it. Cisco excludes Nexus 9000 switches in ACI mode from this advisory.

At the NX-OS CLI, show feature | include ngoam tells you whether NGOAM is enabled. For the extra branches, use show feature | include nve and show feature | include srv6. On switches using NV Overlay, Cisco also gives show running-config | begin "interface nve", show nve vni, and show nve peers to check the NVE mapping and learned peer. An enabled feature by itself is an exposure clue; match it with the platform, overlay state, and installed release.

Disable NGOAM or update NX-OS

Cisco has released fixed software and temporary Live Protect shields for all three flaws. Its separate October NX-OS hardening advisory covers a different set of CVEs with a release table; use the NGOAM advisory’s Software Checker for the first fixed release of each affected platform and installed NX-OS version. Cisco recommends upgrading to fixed software rather than relying on a shield.

If the network can run without NGOAM diagnostics, evaluate the operational impact and disable the feature with no feature ngoam in global configuration mode. Cisco tested that mitigation and says disabling the feature removes the attack vector for all three flaws. Where diagnostics must stay on, plan the fixed-release upgrade; a Live Protect shield is a temporary bridge.

Record the platform, operating mode, installed release, and NGOAM state for each Nexus 3000 or standalone Nexus 9000 switch. Identify networks that can send IP traffic to its interfaces, check the SRv6 or NV Overlay branches where supported, and match that record to Cisco’s NGOAM Software Checker result. After disabling NGOAM, rerun show feature | include ngoam and expect disabled; after an upgrade, confirm the running release matches the fixed release returned for that platform.