Cisco Nexus 3000 and 9000 Series Switches MPLS OAM Remote Code Execution

Cisco's advisory for CVE-2026-76465 describes a pre-authentication remote code execution flaw in NX-OS Software on Nexus 3000 Series and Nexus 9000 Series Switches. The entry point is the MPLS Operation, Administration, and Maintenance (OAM) feature; the trigger is a single crafted MPLS echo-request packet. The vendor rates it critical. It is not currently listed on the CISA Known Exploited Vulnerabilities catalog, and there is no reporting of weaponization against production fleets. That window matters: the gap between a critical advisory for a high-value core switch platform and the first confirmed in-the-wild hit.

This post covers the flaw, the preconditions an attacker needs, and the practical steps defenders can take before this reaches the exploited lists.

What the flaw is

Per the advisory, the root cause is improper validation when an affected device processes an MPLS echo-request packet. MPLS echo-request and echo-reply are the message types defined by RFC 8029 (formerly RFC 4379) for Label Switched Path (LSP) ping and traceroute. They are carried as IP/UDP packets to destination port 3503, with a TLV-encoded payload that tells a Label Switching Router (LSR) which forwarding equivalence class, pseudowire, or RSVP tunnel the sender is probing. The attack surface is an input parser inside the control-plane process that handles LSP ping, reachable without credentials or prior session state.

A successful exploit yields arbitrary code execution with root privileges on the switch, or a denial of service if the parser crashes rather than producing a usable primitive. Root on a core or spine switch is not a quiet outcome. It gives an attacker arbitrary dataplane manipulation, access to the running configuration (including TACACS keys, RADIUS secrets, and routing protocol passwords), the ability to install stealth ACLs or VRF leaks, and a foothold with reboot persistence depending on the implant technique.

The precondition an attacker needs

A critical advisory headline does not mean every box running a vulnerable image is reachable. Three conditions must hold simultaneously for an attacker to reach code execution.

  1. The switch runs an affected NX-OS release on an in-scope Nexus 3000 or Nexus 9000 platform. Cross-reference your running image against the fixed releases in the vendor advisory.
  2. MPLS OAM is enabled. On NX-OS, that means the MPLS OAM process is active, or the device participates in LSP ping and traceroute as part of a broader MPLS deployment. A pure L2 top-of-rack in VXLAN EVPN or classic Ethernet access mode will typically not have the parser engaged.
  3. The attacker can deliver a UDP packet with the right destination parameters to an IP address configured on the device. The advisory specifies that an MPLS echo-request is sent to an IP address on the affected device.

That last condition is the one most environments misjudge. Operators often assume MPLS control-plane traffic is confined to a trusted P/PE core, but Nexus platforms are frequently deployed in dual-role positions: a 9000 acting as a datacenter PE, a 3000 bridging a provider handoff, a leaf exposing a management SVI, or a spine with an in-band management loopback reachable from a jump host on a flat corporate VLAN. If any routable IP on the box can receive a UDP/3503 packet from a position an attacker can reach, the box is in scope.

How to determine exposure

Three checks, in order. Treat them as minimum due diligence before returning to steady-state operations.

First, confirm whether MPLS OAM is active anywhere in the fleet. From the device:

! On an NX-OS switch
show feature | include mpls
show mpls oam
show running-config | section 'feature mpls'

! From a controller or Ansible inventory, enumerate across the fleet
ansible nexus -m nxos_command -a "commands='show feature | include mpls'"

Second, map the IP footprint of every switch that returns with the feature enabled. For each affected device, list every interface with an IPv4 or IPv6 address, including loopbacks, management SVIs, and VRF-leaked addresses. Those are the destinations an attacker must reach to deliver the crafted echo-request.

Third, model which of those addresses are reachable from untrusted positions. The useful question is not "is this device on a management network." It is "can a host that an attacker could compromise send a UDP packet to any address on this device, and will the control plane process it." Flat corporate networks, VPN concentrators that terminate into shared segments, and jump hosts with poor egress ACLs will all surface here.

A conservative sweep from an authorized position confirms what the paper exercise suggests:

# UDP/3503 reachability check from an authorized test host.
# Replace targets with the loopbacks and management addresses you enumerated.
sudo nmap -sU -p 3503 -Pn --reason \
  -oA mpls-oam-reachability \
  switch-core-01.example.com switch-core-02.example.com

Open or filtered responses from positions that should not reach the control plane are the finding, not the exploit.

What to do before this reaches the KEV lists

CISA tracks confirmed in-the-wild exploitation. The current remediation directive, BOD 26-04 (Prioritizing Security Updates Based on Risk), carries the KEV criteria forward from its predecessor. For a federal agency, the moment a CVE lands in KEV, remediation becomes a legal obligation on the schedule the catalog publishes. For everyone else, KEV remains the single best signal that opportunistic scanning has started.

This CVE is not yet in that catalog, but the advisory profile (unauthenticated, remote, root, single packet) is the exact shape that historically moves fast. Three actions buy the most defense per hour spent.

Patch the affected images. The vendor's advisories for the NX-OS OAM family note no workarounds, including the sibling Next Generation OAM remote code execution issues tracked as CVE-2026-76485, which share the same unauthenticated remote root profile and are triggered by crafted IP packets to an interface when NGOAM is enabled. If you are already in a change-controlled upgrade cycle, include these. If not, the critical rating is sufficient justification to start one.

Shrink the control plane's exposure. Apply a Control Plane Policing (CoPP) policy that drops MPLS OAM (UDP/3503) from any source that is not an authorized peer, and enforce the same filter at edge ACLs. This does not fix the parser, but it collapses the reachable surface to the subset that genuinely needs it.

Hunt for preconditions, not the exploit. Signatures for a one-shot UDP RCE will arrive late. Inventory which switches have MPLS OAM enabled, which addresses they listen on, and which of those addresses are reachable from untrusted segments. That inventory is also what you will need the day this hits KEV, so the work pays twice.

Finally, note the lesson that recurs each time a KEV entry lands against a protocol most networks consider unexposed. The two Zammad entries added to KEV on 2026-10-02 (CVE-2026-102489 and CVE-2026-102490) chain a session fixation primitive into a local privilege escalation to reach root on the host. The pattern is consistent: a feature meant to be reachable only by trusted callers turns out to be reachable by everyone, and a parser meant to receive well-formed input turns out not to validate it. Treat every unauthenticated, remote, root advisory on infrastructure as the start of that clock.

Verifiable security.