Cisco Nexus 9000 Flaw CVE-2026-20212 (CVSS 9.8) Lets Unauthenticated Attackers Run Code as Root

Cisco has patched a critical flaw in its Nexus 9000 data-center switches, tracked as CVE-2026-20212 and rated 9.8 on the CVSS scale, that lets an unauthenticated remote attacker execute code as root on 10 Silicon One-based models. The company disclosed the bug on September 2, and on the same day shipped a separate IOS XR hardening release that bundles seven CVEs, two of them also rated 9.8, with no workaround for any IOS XR version. The Hacker News and The Register reported both advisories this week.

Read together, the two disclosures point at one place: the core of the network. The switches that move traffic inside a data center and the carrier-grade routers that run IOS XR are the machinery most organizations treat as static plumbing, patched late and rarely. This cycle they are the priority, because one advisory hands an unauthenticated attacker root on a switch and the other leaves an entire router operating system with fixes but no stopgap.

What CVE-2026-20212 Actually Breaks

The Nexus flaw is a case of binding a service to an unrestricted IP address, classified as CWE-1327. Cisco's advisory says TCP ports 43210 and 43211 are, in its words, "accessible in the default Layer 3 (L3) virtual routing and forwarding (VRF)." An attacker who can reach a switch on either port can connect to the service directly, and crafted input sent to it is executed as code with root privileges, per Cisco's Nexus 9000 advisory. An exploitation attempt can also crash the S1HAL process and reload the device, so the same defect that yields code execution can also knock a switch offline.

That combination, unauthenticated and remote and root and reachable in the default VRF, is why the score sits at 9.8. There is no privilege requirement, no user interaction, and low attack complexity. What makes the exposure sting is where these parts live: Silicon One is the processor Cisco pitches for high-throughput and AI data-center fabrics, so the affected switches are not edge afterthoughts but the boxes carrying an organization's densest internal traffic. The CyberSignal is not publishing exploitation detail. The point for defenders is scope, not method.

Which Nexus 9000 Models Are Affected

Cisco lists 10 affected product identifiers, checkable against the output of the show module command. The Hacker News, citing the advisory, names them as:

• N9324C-SE1U (Nexus Smart Switch)
• N9348Y2C6D-SE1U (Nexus Smart Switch)
• N9364E-SG2-O
• N9364E-SG2-Q
• N9396T12C-SE1
• N9348Y12C-SE1
• N9396Y12C-SE1
• N9336C-SE1
• N9K-C9804
• N9K-C9808

Cisco says other Nexus 9000 models, Nexus 9000 fabric switches running in Application Centric Infrastructure (ACI) mode, and the Nexus 3000 and 7000 lines are not affected. The common thread among the vulnerable devices is the Silicon One networking processor, and the root cause is a bad integration with that silicon rather than a configuration mistake an operator made. According to the CVE Program's record, Cisco lists NX-OS releases from 10.3(1) through 10.6(3s) as affected, a range the advisory itself defers to the Software Checker.

There Is No Full Fix Yet for the Nexus Flaw

This is the uncomfortable part. As The Register put it, this is a bug you can mitigate but not yet fix outright: Cisco has not published a fixed-release table for the Nexus advisory and instead directs customers to its Software Checker. Until a fixed release is confirmed for a given box, Cisco offers three options, in rough order of durability:

• Upgrade to the release named by the Software Checker. Cisco's Live Protect shield notes say the shield's operational mode moves to N/A once a switch reaches NX-OS 10.6(4) or higher, which is the signal that the box is on fixed code.
• Infrastructure access control lists (iACLs) that permit only required management and control-plane traffic, or that explicitly deny TCP packets destined to a locally configured IP address on port 43210 or 43211. Cisco says it validated this approach in a test environment, and it is the mitigation to reach for first if you cannot upgrade today.
• The Live Protect shield lp00031, a temporary measure supported only on NX-OS 10.6(3), and on 10.6(3s) for the two Smart Switches through a second shield package. It is unsupported on the Nexus 9804 and 9808 and needs SSH, Telnet, or NX-API access to deploy.

Cisco's Product Security Incident Response Team said it was not aware of any malicious use of CVE-2026-20212 as of the September 2 disclosure, and the CVE is not listed in CISA's Known Exploited Vulnerabilities catalog as of this writing. That is a window, not an all-clear. A switch you cannot patch this week should at least get the iACL, and the broader habit the advisory rewards is keeping the management plane of core switches off any path an untrusted host can reach.

The IOS XR Hardening Release Reaches Every Version

The second advisory is a different shape of problem. Cisco's IOS XR software hardening release assigns one CVE to each category of internally found bug and scores it at the most severe defect in that bucket. Seven CVEs came out of the review, CVE-2026-20274 through CVE-2026-20280, and two carry a 9.8 ceiling:

• CVE-2026-20274 covers memory-safety and resource-lifetime bugs, including buffer handling, out-of-bounds writes, and insecure default initialization.
• CVE-2026-20279 covers access-control failures. Cisco describes the bucket as spanning improper certificate validation, missing authentication for a critical function, missing authorization, and incorrect authorization.

The remaining five, CVE-2026-20275, CVE-2026-20276, CVE-2026-20277, CVE-2026-20278, and CVE-2026-20280, top out between 8.2 and 8.8. The advisory says the vulnerabilities affect all releases regardless of device configuration, and, critically, that there is no workaround for any of them. Patching is the only path.

Doing that patching is not a single click. Cisco is delivering fixes through software maintenance updates (SMUs), and says roughly 16 SMUs may be available per release, with future releases 26.2.2 and 26.3.1 set to be the first fixed builds that need no SMUs at all. The XR7 (LNT) platforms, which include the Cisco 8000 Series, NCS 1010, NCS 540L, and NCS 5700 Series, get a dedicated SMU that applies across all releases. When The Hacker News cross-checked the seven CVE records against the advisory, it found that of the 111 IOS XR releases Cisco lists as affected, only 14 have SMUs available now, four are awaiting them, and 93 must be upgraded before a fix can be applied. For a lot of operators, in other words, the fix is a version upgrade, not a patch, and the planning starts with knowing which train each router runs.

The cadence is worth noting on its own. This September 2 drop is the third scheduled hardening release Cisco has issued in 30 days, following an August wave of Catalyst SD-WAN and IOS XE fixes, part of a twice-monthly model the company adopted to group internally discovered bugs into umbrella CVEs. The upside is predictability. The downside is that a routine internal security review now regularly produces critical-rated findings across the products that run the internet's plumbing, which is exactly the class of gear a China-nexus actor was recently found living inside on IOS XR routers, without any named vulnerability at all.

Cisco operator response checklist for CVE-2026-20212 and the IOS XR hardening release. Source: Cisco advisories via The Hacker News and The Register.

My Read

My read: unauthenticated root on data-center switches plus a no-workaround router-OS bundle means the core network is the patch priority this cycle, ahead of the usual endpoint-and-app scramble. This is an assessment, not a Cisco statement, but the logic is straightforward. The Nexus flaw gives an attacker the highest possible privilege on a device that sits in the traffic path, and the IOS XR release removes the comfortable option of buying time with a config change. Organizations that treat switches and routers as set-and-forget infrastructure are the ones most exposed here, because their patch windows for that gear are usually measured in quarters. The teams that come out of this well will already know which of their Nexus 9000s carry Silicon One and which IOS XR trains they run. That is ordinary vulnerability management discipline, inventory first and then prioritize by exposure, applied to the gear that usually gets skipped. If you have to choose, the Nexus iACL is the fastest risk reduction, and the IOS XR upgrades are the longer, unavoidable slog.

What Is Not Confirmed

A few things are worth stating plainly. Cisco reports no known exploitation of CVE-2026-20212 as of September 2, and neither advisory names a victim organization, so any specific target attached to these bugs would be inference. CVE-2026-20212 is not in CISA's KEV catalog at publication, which is consistent with the no-exploitation note but could change if that status is updated. Fixed-version specifics for the Nexus flaw are deferred to Cisco's Software Checker rather than stated in a table, so the exact target release depends on your model and current build. And the IOS XR fix status varies sharply by release: confirm your own train against the advisory rather than assuming an SMU already exists.

Primary Documents

• Cisco Security Advisory: Nexus 9000 Series Silicon One RCE (CVE-2026-20212)
• Cisco Security Advisory: IOS XR Software Security Hardening Release, September 2026
• The Hacker News: Critical Cisco Nexus 9000 Flaw Lets Unauthenticated Remote Attackers Run Code as Root (Sept. 3, 2026)
• The Register: Cisco Searched for IOS XR Bugs and Found So Many It Rolled Them Into an Update Release (Sept. 4, 2026)