Root Without a Password: Critical Flaw in Cisco Nexus 9000 Switches with Silicon One ASICs Lets Attackers Execute Code Unauthenticated (CVE-2026-20212, CVSS 9.8)

Published: September 3, 2026 Category: Information Security · Vulnerabilities · Data Center Networking · Critical Infrastructure

Context: What Happened

On September 2, 2026, Cisco published security advisory cisco-sa-n9k-s1-rce-EH8dEtr, fixing a critical vulnerability tracked as CVE-2026-20212, scored at 9.8 out of 10 on the CVSS scale — just shy of the maximum possible. The flaw affects ten models in the Cisco Nexus 9000 line, the switches that serve as the backbone of countless enterprise data centers, specifically those built around Silicon One processors: the family of ASICs (Application-Specific Integrated Circuit, a chip custom-built for one narrow job — in this case, forwarding network packets at very high speed) that Cisco uses in its newest switching hardware.

The technical root cause, classified as CWE-1327 (“binding to an unrestricted IP address”), boils down to a network-exposure oversight, no jargon required. Two TCP ports, 43210 and 43211, are reachable through the switch’s default Layer 3 VRF (Virtual Routing and Forwarding) instance. A VRF is essentially a logical partition of a switch’s routing table: it lets a single physical device maintain several isolated “virtual networks” side by side, so that, for example, management traffic can be kept separate from production traffic. The problem is that on the affected devices, the service listening on those two ports was never restricted to a trusted management interface — it bound instead to any address reachable through the default routing instance, meaning it could be visible from any network segment with a route to the switch, not just the management network an operations team would expect.

An attacker who can reach either port can connect directly to the exposed service and send it specially crafted input. That input ends up executing as code with root privileges — the superuser account with total control over the device’s operating system, able to read, change, or delete anything on it. And all of this without the attacker ever presenting a valid credential or completing a single login step.

Cisco found the bug internally, while resolving a Technical Assistance Center (TAC) support case, not through an outside researcher or a bug bounty submission. The company says it has no knowledge of any public disclosure or malicious use of the flaw as of the advisory’s publication.

CVE-2026-20212 didn’t arrive alone. That same September 2, Cisco also released an IOS XR hardening update — the operating system for a separate line of network gear, distinct from the Nexus switches — bundling seven “umbrella” CVEs (a practice where Cisco assigns a single CVE per category of fixed bugs, scored at the severity of the worst bug in that bucket) that, per the company, affect every IOS XR release regardless of configuration; two of those seven also carry a 9.8 score. That batch covers routers, not the switches this article is about, but its simultaneous release illustrates the sheer volume of findings Cisco is now processing under its twice-monthly disclosure model, adopted explicitly in response to what the company itself describes as an acceleration in vulnerability discovery.

The Problem: Why a 9.8 Isn’t Hype

A CVSS (Common Vulnerability Scoring System) score of 9.8 isn’t decoration. On a 0-to-10 scale, it summarizes how easy a flaw is to exploit and how bad the resulting damage is. CVE-2026-20212’s full vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, and each piece adds its own reason to take it seriously:

Put together, this describes the worst-case scenario for a piece of network hardware: anyone who can send traffic to those two ports, with no credentials and no prior steps, can walk away with total control of it. That control amounts to remote code execution (RCE): the ability to make a system run instructions the attacker chose, from anywhere, without ever touching the hardware. And because that execution lands directly in a root context here, the attacker skips the usual privilege-escalation step entirely — initial compromise and full control arrive in the same move.

The Extra Risk: An S1HAL Crash

Beyond code execution, Cisco warns that an exploitation attempt — even a failed or malformed one — can crash the S1HAL process, the software layer that bridges NX-OS (these switches’ operating system) and the Silicon One ASIC itself. If that process goes down, the whole device reboots. That adds a second failure mode, denial of service (making a system or service unusable for its legitimate users): an attacker who never manages to get code running successfully can still knock the switch offline, with whatever traffic disruption that causes for everything that depends on it.

Which Devices Are at Risk

The vulnerability affects only Nexus 9000 switches that include a Silicon One ASIC. As of publication, Cisco identified ten vulnerable product identifiers (PIDs), which can be checked with the show module command:

Worth noting: two of those ten, the N9K-C9804 and N9K-C9808, are high-capacity modular chassis — the kind of hardware more likely to sit at the core of a large fabric than at its edge.

Cisco was explicit about what isn’t affected: every other Nexus 9000 model not on that list, Nexus 9000 switches running in Application Centric Infrastructure (ACI) mode, and the entire Nexus 3000 and 7000 lines. Other product families — including Firepower and Secure Firewall appliances, MDS 9000 switches, and UCS fabric interconnects — aren’t affected either.

On the software side, The Hacker News confirmed, after cross-checking the advisory against the official CVE Program record, that 45 separate NX-OS releases, from 10.3(1) through 10.6(3s), are listed as affected. Cisco didn’t publish a simple “fixed version” table for this advisory; instead, it points customers to the Cisco Software Checker to work out the exact upgrade path for their platform and installed release. One useful clue: the release notes for the temporary mitigation shield state that its operational mode switches to “N/A” once a device is upgraded to NX-OS 10.6(4) or later — suggestive, though not an explicit confirmation in the advisory itself, that this branch already carries the permanent fix.

A Brief Analysis: When the Target Is the Network’s Plumbing

There’s a structural difference between compromising a server and compromising a data center’s core switch. A compromised server hands an attacker control of that server. A compromised core switch hands them a vantage point — and potentially a lever — over everything that flows through it: the traffic between the applications, databases, and storage systems an organization works hardest to protect at every other layer. And it’s a layer of infrastructure that, in practice, gets considerably less day-to-day monitoring than servers and endpoints do.

That imbalance — high-value infrastructure paired with comparatively light scrutiny — helps explain why a flaw this severe in trunk-level switching gear isn’t an isolated event, even within Cisco’s own ecosystem. Just six days before this advisory, incident-response firm Sygnia had documented that a suspected China-nexus threat actor known as Fire Ant — first identified in 2025 — had deployed purpose-built implants on IOS XR routers to suppress syslog delivery, filter diagnostic command output, and maintain a hidden GRE (Generic Routing Encapsulation) tunnel, alongside capturing network packets for exfiltration to external FTP servers and probing connected systems tied to critical infrastructure. Sygnia never determined how the actor gained initial access to those routers; the investigation reportedly began after analysts noticed a live tunnel interface on a device with no configuration change or commit history to explain it.

Neither incident proves the other is connected — Fire Ant exploited IOS XR routers through a vector that’s still unidentified, while CVE-2026-20212 is an unrelated flaw in Nexus switches. But together they make the same underlying point: the gear that routes and switches an organization’s traffic has become a target of sustained interest, and compromising that layer — quiet, lightly audited, and with authority over everything passing through it — is a risk that reaches well beyond any single organization, extending to any business service that depends on that network, directly or otherwise.

Security Recommendations for Network Administrators

Cisco reports no active exploitation of CVE-2026-20212 as of this writing, but it’s worth keeping in mind what Cisco’s own VP of information security, Russ Smoak, said in a June blog post about the company’s new disclosure model: “the window between disclosure and exploitation has effectively closed.” In other words, no known exploitation today describes the present, not a guarantee about the days ahead. With that in mind, here’s what to prioritize:

1. Upgrade to a fixed NX-OS release as soon as possible. Since Cisco didn’t publish a simple fixed-version table for this advisory, the reliable path is running the Cisco Software Checker against the exact version installed on each device to get the applicable upgrade path for that platform.

2. Check your actual exposure. Run show module on every Nexus 9000 and compare the product ID against the list of ten affected models. Exposure doesn’t require internet-facing hardware — it’s enough for ports 43210 or 43211 to be reachable from a less-trusted, or already compromised, internal segment.

3. Deploy an iACL (infrastructure access control list — an ACL built specifically to protect the network device itself, not to filter traffic passing through it) while the upgrade is pending. Cisco recommends permitting only the management and control-plane traffic that’s strictly necessary, or explicitly denying TCP traffic destined for ports 43210 and 43211 on the device’s locally configured address. Cisco tested this mitigation successfully in a lab environment, but stresses that every organization should validate its own applicability and potential impact before deploying it in production.

4. Turn on the temporary “Live Protect” shield (lp00031) wherever the hardware and software version support it. Built on eBPF (Extended Berkeley Packet Filter — a Linux kernel capability that lets security rules run in a programmable way without patching or rebooting the system), it applies a Cisco-validated compensating control with no maintenance window required. It’s available only for NX-OS 10.6(3), and, via a separate package, 10.6(3s) on the two Smart Switch models; it is not supported on the N9K-C9804 or N9K-C9808 chassis, and deploying it requires prior SSH, Telnet, or NX-API access. Cisco is clear that this is a temporary bridge, not a substitute for patching.

5. Watch for anomalous traffic and behavior. Keep an eye out for unexpected switch reboots or S1HAL process crashes — a possible sign of a failed or exploratory attack — as well as unusual connections to ports 43210 and 43211 from segments that have no business reaching them.

6. Don’t mistake “no known exploitation” for “no risk.” An unauthenticated, low-complexity remote code execution flaw in core network infrastructure is exactly the kind of bug that tends to draw fast reverse-engineering once it’s public.

Wrapping Up

CVE-2026-20212 combines three traits that rarely show up together: it’s exploitable remotely and without authentication, it hands over root-level code execution in the same step, and it hits equipment that forms the switching core of a data center rather than some peripheral service. The technical root cause — two management ports bound to an unrestricted IP address instead of a trusted management interface — is at once simple to explain and severe in its consequences.

Cisco’s response was disciplined: fixed software, a lab-tested network mitigation, and a fast-to-deploy temporary shield, all released the same day. For teams running Nexus 9000 switches with Silicon One ASICs, the immediate task leaves little room for nuance: confirm whether your hardware is on the affected-model list, apply the appropriate update via the Software Checker, and, in the meantime, lock down ports 43210 and 43211 with an iACL. No reported exploitation so far is a good starting point — not a reason to put any of that off.

Sources:

• Khandelwal, S. “Critical Cisco Nexus 9000 Flaw Lets Unauthenticated Remote Attackers Run Code as Root” — The Hacker News (September 3, 2026)
• Cisco. “Cisco Nexus 9000 Series Switches Silicon One Remote Code Execution Vulnerability” — Cisco Security Advisory cisco-sa-n9k-s1-rce-EH8dEtr (September 2, 2026)
• CVE Program. “CVE-2026-20212”
• Centre for Cybersecurity Belgium (CCB). “Warning: Critical Remote Code Execution Vulnerability - NX-OS, Patch Immediately!”
• eSecurity Planet Staff. “Critical Cisco Nexus 9000 Flaw Allows Remote Root Code Execution” — eSecurity Planet (September 3, 2026)
• Khan, S. “CVE-2026-20212: The Cisco Nexus 9000 Bug That Turns a Management Port Into Root Access” — XHack (September 3, 2026)