The API your automation switched on is the one the attacker needs

On October 7, Cisco published a batch of security advisories for NX-OS, the operating system that runs its Nexus data center switches. Buried in the batch were five flaws that let an unauthenticated attacker on the network run code as root on the switch. No login. No credentials. Just crafted network traffic, and the box that carries your whole data center fabric is compromised.

The part that stuck with me is not the severity. A CVSS 9.8 is a number we see every month. It is who turned the attack surface on.

The locked door that ships locked

Take NX-API first. NX-API is a JSON and XML interface over HTTP for managing the switch. Instead of typing commands into the CLI, your automation talks HTTP: Ansible playbooks, Terraform providers, SDN controllers, the CI pipeline pushing config at 2am. It is the switch's management API, built for machines, not humans.

Cisco ships it disabled. On Nexus 3000 and 9000 switches, NX-API sits off by default, and nothing turns it on except a working network: someone enabling it so the tooling can do its job.

CVE-2026-76471 is a heap buffer overflow in NX-API, reached through a crafted HTTP request. An attacker who can reach the management interface sends one bad request, and the parser that was built to serve your automation becomes the path to root on the device. There is no login step in the chain. The API was built for machines, and the attack is a machine sending bytes.

A quick explainer, because the words matter. A buffer overflow means the program reads more data into a fixed-size memory region than the region can hold. The extra data spills into neighbouring memory. A heap buffer overflow means the spilling happens in the heap, the program's dynamic memory area. When that memory belongs to privileged code, the attacker can overwrite the program's own control structures and steer it. Steering privileged code means root.

On the UCS 6300 fabric interconnects, the same CVE rides a different gate. There the vulnerable API is the UCS Manager XML API, enabled by default and impossible to switch off without breaking management. Exploitation there needs a valid low-privileged login, so Cisco rates that variant High rather than Critical. One CVE, two platforms, two different gates.

The monitoring plane is an attack surface too

The second cluster lives in NGOAM, Next Generation Operation, Administration, and Maintenance. NGOAM is the feature that verifies path health on Nexus switches: it checks that the data center fabric is actually carrying traffic the way you think it is. It is monitoring infrastructure, the kind of thing you enable and forget.

Three CVEs, each CVSS 9.8: CVE-2026-76485, CVE-2026-76486, CVE-2026-76501. All three are stack-based buffer overflows from improper input validation, reached with crafted IP packets sent to the switch. CVE-2026-76485 needs only NGOAM enabled. CVE-2026-76486 needs NGOAM plus SRv6 or an NV Overlay. CVE-2026-76501 needs NGOAM plus SRv6. (SRv6 is Segment Routing over IPv6, a way of steering traffic by encoding the path in the packet header. NV Overlay is network virtualization, the VXLAN-based overlay most data center fabrics run on.)

The pattern repeats: a feature that exists to let the network be managed and observed is the one parsing untrusted input in privileged code.

No workarounds

Cisco's position is unusually flat. For these advisories, the workaround section is effectively one sentence: there are none. No configuration change, no ACL, no knob that removes the exposure.

The temporary bridge is a Live Protect shield for CVE-2026-76471, which Cisco describes as a stopgap until upgrades can be scheduled. The permanent fix is the upgrade you keep postponing. The NX-API advisory does not print version strings; it sends operators to the Cisco Software Checker for the first fixed release on each platform and version.

At publication, Cisco's PSIRT said it was not aware of public announcements or malicious use of these flaws. The flaws surfaced during Cisco's internal security testing, which Cisco says combined its existing testing processes with frontier AI models. Make of that what you will. The bugs are real either way.

One line of wider context: the same October 7 publication cycle also carried a License On-Prem advisory with a CVSS 10.0 signature verification flaw, CVE-2026-76482. Separate product, separate advisory, same day, same lesson.

Which side of the line is your fleet on?

The audit is one command. On any Nexus 3000 or 9000 in standalone NX-OS mode:

show feature | include nxapi

If it comes back enabled, that switch has the management-plane exposure until it is upgraded. For NGOAM, the question is whether the monitoring feature is on, and whether SRv6 or NV Overlay rides alongside it.

The uncomfortable takeaway: this exposure is not a misconfiguration in the classic sense. Nobody typed a bad password or left a port open by accident. The features exist to let machines manage the switch, and the machine-centric workflow, your automation, is what enables them. Programmability is the attack surface. The safe default and the working network are the same decision, and right now the decision is an upgrade.

When was the last time you checked which features your fleet has on that you did not personally enable?

Further reading: Cisco's NGOAM advisory cisco-sa-ngoam-rce-LWKQ4BU, the Forkast deep dive on the NX-API flaw, and ThreatAft's full October 7 roundup.