Cisco NX-OS Software NX-API Remote Code Execution

Cisco's advisory for CVE-2026-76471 describes an unauthenticated remote code execution path in the NX-API feature of NX-OS. In the vendor's own words, the vulnerability "is due to insufficient input validation of data that is sent to the NX-API," and an attacker can exploit it "by sending a crafted HTTP request to the NX-API of an affected device." A successful exploit yields arbitrary code execution with root privileges on the switch; failed exploitation crashes processes and triggers a reload.

The finding is pre-authentication, network-reachable, and delivers root on a data-plane device inside the trust boundary of nearly every datacenter it runs in. At the time of writing, CVE-2026-76471 has not appeared on CISA's Known Exploited Vulnerabilities catalog, so defenders still hold the initiative. This post is about keeping it.

What NX-API is, and why it matters

NX-API is the HTTP/HTTPS management interface Cisco ships for programmatic configuration of Nexus switches. It exposes CLI commands over a REST-style endpoint, typically on TCP/80 or TCP/443, used by automation stacks to template config, pull operational state, or drive change through CI pipelines rather than SSH-driven expect scripts. On a switch where NX-API is enabled, that endpoint listens on whatever management interface the device uses; in many deployments that is a shared out-of-band management VLAN reachable from a jump host, a configuration management server, and sometimes an engineer's workstation.

The vulnerability is in that endpoint's input validation. The advisory does not describe the exact malformed field, and we will not speculate. What matters operationally: if an attacker can reach NX-API over HTTP, that attacker can attempt exploitation. No authentication gate sits in front of the vulnerable code path. No cryptographic precondition exists. The only prerequisite is reachability.

Preconditions

Three conditions, all environment properties rather than attacker capabilities:

  1. NX-API must be enabled on the target switch.
  2. The attacker must be able to deliver a TCP connection to the NX-API listener.
  3. The attacker must be able to craft the triggering HTTP request. The vendor advisory is the authoritative source for the condition that trips the bug; proof-of-concept detail is not in the public material and we will not fabricate it.

Items one and two are what defenders control. If NX-API is off, nothing listens. If NX-API is on but only reachable from a hardened management segment an outside attacker cannot access, exploitation requires a prior foothold, which raises the cost materially even if it does not eliminate the risk.

Determining exposure

Start by enumerating which switches have NX-API enabled. On a Nexus device, NX-API state appears in the running configuration and in the operational show commands. Example on a lab unit at nxos.example.com:

nxos.example.com# show nxapi
nxapi enabled
HTTP Port: 80
HTTPS Port: 443
Certificate Information:
    Issuer:   /CN=nxos.example.com
    Expires:  2027-04-11

nxos.example.com# show running-config | include "feature nxapi|nxapi"
feature nxapi
nxapi http port 80
nxapi https port 443

If feature nxapi is absent and show nxapi reports the feature as disabled, the device is not exposed to this flaw regardless of patch state. If it is enabled, treat the device as in scope until it runs a fixed build.

Next, confirm which network paths reach the listener. From an authorized scanning host, a controlled probe looks like:

$ curl -sk --max-time 5 -o /dev/null -w "%{http_code}\n" \
    https://nxos.example.com/ins
401

A 401 or any other response confirms the service is reachable from that source. Correlate the hosts that can reach each switch's NX-API port with your inventory of what should legitimately speak to it: automation controllers, orchestration bastions, and operator jump hosts. Any other host that can land TCP on that port is exposure you did not know you had.

Finally, pull the running NX-OS image version from each in-scope device and compare it against the fixed releases in Cisco's advisory. The advisory identifies software updates as the remediation. Patch on the strength of the pre-auth root exposure; do not wait for the CISA KEV catalog to force action. BOD 26-04 obligations engage only when a CVE lands on the catalog, and this one has not appeared there yet.

The companion finding: NX-OS NGOAM RCE

The same advisory batch covers CVE-2026-76485, affecting Next Generation OAM (NGOAM) on Nexus 3000 and 9000 series switches. The vendor describes an unauthenticated remote attacker executing arbitrary code with root "by sending crafted packets to an IP interface on an affected device" when NGOAM is enabled. CVE-2026-76471 and CVE-2026-76485 target different code paths with different triggers, but share the same blast radius: pre-auth root on a switch, with DoS as the degraded outcome. If you are auditing NX-API exposure, audit NGOAM at the same time. The feature's own show commands and show running-config | include ngoam confirm whether that plane is active.

What to do before this reaches KEV

Four moves, in order:

  1. Patch the switches that have NX-API or NGOAM enabled, prioritizing those whose listener is reachable from anything beyond a tightly controlled management segment.
  2. Where patching lags, disable the feature if business logic allows. no feature nxapi removes the attack surface entirely on devices that do not need programmatic management.
  3. Constrain reachability. NX-API traffic from a general corporate VLAN, or worse from the internet, is a configuration defect regardless of patch state. Infrastructure ACLs on the management interface, or an upstream firewall ruleset, should enumerate exactly which source addresses may speak to the NX-API port.
  4. Instrument detection. Netflow or firewall logs showing new source addresses initiating connections to the NX-API port of a Nexus switch are a high-signal event in almost every environment; the set of hosts that should legitimately do so is small, enumerable, and changes slowly.

KEV additions follow confirmed in-the-wild exploitation. By the time BOD 26-04 obligations attach to this CVE, someone has already been compromised. The window between advisory publication and in-the-wild use is where defenders either close the exposure or inherit it.

Verifiable security.