Same Day, Two Advisories: Cisco's Nexus 9000 Root RCE and the IOS XR Hardening Bundle

Cisco’s Product Security Incident Response Team published four advisories on 2 September 2026: a critical, unauthenticated root RCE on Nexus 9000 switches, a seven-CVE IOS XR hardening bundle with no workaround anywhere in the product line, a phone denial-of-service bug, and a pair of S/MIME decryption flaws in Secure Email. The first two are the ones worth a full stop.

CVE-2026-20212: Nexus 9000, unrestricted bind, root

This one affects ten specific Silicon One-based Nexus 9000 models: the N9324C-SE1U and N9348Y2C6D-SE1U Smart Switches, four N9364E/N9396/N9348 variants, the N9336C-SE1, and the chassis-based N9K-C9804 and N9K-C9808. Other Nexus 9000 hardware, anything running in ACI mode, and the Nexus 3000 and 7000 lines are unaffected.

The root cause is a service binding to an unrestricted IP address, leaving TCP ports 43210 and 43211 reachable in the default Layer 3 VRF. Anyone who can reach a switch on either port can connect directly to that service, and crafted input sent to it executes as code with root privileges. A failed or partial exploitation attempt can also crash the S1HAL process and reload the switch outright, so this is a denial-of-service risk even for an attacker who doesn’t land the RCE cleanly.

Cisco says it isn’t aware of any exploitation as of the disclosure date, which puts this in the same category as most of what this site has covered this year: not yet a live incident, but a bug with nothing standing between disclosure and a working exploit except whoever gets there first. Cisco has published no fixed-release table for this one and instead points customers at its Software Checker tool. Until a confirmed fix is in hand, the stopgaps are an infrastructure ACL blocking or restricting the two ports, and a temporary mitigation called a Live Protect shield (package lp00031), supported only on NX-OS 10.6(3) and, for the two Smart Switch models specifically, 10.6(3s). It isn’t supported at all on the 9804 or 9808 chassis switches, and it needs SSH, Telnet, or NX-API access to apply. Cisco’s own release notes state that the shield’s operational mode simply becomes not applicable once a device is upgraded to NX-OS 10.6(4) or later, which is a useful tell for confirming a device has actually moved past the vulnerable range.

The IOS XR hardening release: the third one of these this year

The same day, Cisco shipped an IOS XR release bundling seven CVEs under its risk-based disclosure model: one CVE assigned per CWE bucket of internally-found bugs, scored at the severity of the worst bug in that bucket. This site has covered this disclosure model twice already, once for Catalyst SD-WAN in August and again for IOS XE two weeks later. IOS XR is the third product line to get the same treatment inside a single month, which is a genuinely fast cadence for a model Cisco only announced in June.

CVE-2026-20274 covers memory-safety and resource-lifetime bugs, and CVE-2026-20279 covers access-control issues, missing authentication for critical functions and improper certificate validation among them. Both carry the ceiling score of 9.8. The remaining five, CVE-2026-20275 through 20278 and CVE-2026-20280, run between 8.2 and 8.8. Every one of them affects every IOS XR release regardless of configuration, and there is no workaround for any of them, which is the detail that actually matters more than any individual CVSS number: a device with nothing turned on that’s exploitable still needs the fix.

Remediation here is messier than a normal advisory. Cisco isn’t shipping fixed point releases, it’s shipping SMUs (software maintenance updates) against specific existing releases, and coverage is uneven. Of the 111 IOS XR releases Cisco lists as affected, roughly a third already have an SMU available, a handful more are still waiting on one, and the majority need an upgrade to a covered release before a fix can even be applied. The XR7 (LNT) platform family, which includes the Cisco 8000 Series and the NCS 1010/540L/5700 lines, gets one SMU that applies across every release in that family. Cisco says releases 26.2.2 and 26.3.1, both still upcoming, will be the first to ship with the fix built in rather than needing a separate SMU at all.

Why “no workaround, every release” is the detail to sit with

Six days before this release, Sygnia published research on Fire Ant, a China-nexus actor first documented in 2025, running purpose-built implants on IOS XR routers that suppressed syslog delivery, filtered the output of show commands, and maintained a hidden GRE tunnel. The investigation started because someone found a tunnel interface active on a router with no configuration or commit history to explain it, which Sygnia’s report puts plainly: the device’s operational state “could no longer be trusted to match the configuration and audit records.” Sygnia never identified how Fire Ant got in, and they name no vulnerability at all.

I’m not suggesting any of the seven CVEs in this release are what Fire Ant used. Cisco doesn’t say that and neither does Sygnia. But it’s worth naming the two stories next to each other anyway, because they land on the same point from opposite directions. This hardening release covers bugs affecting every release with no workaround, which means a router can be sitting exposed through no configuration decision anyone on that team made. Fire Ant is a live demonstration of what an actor with router-level access, however it was obtained, can actually do once they’re in: not just read traffic, but selectively lie to the tools an operator would use to notice them. A router whose own show output and syslog have been quietly filtered is the control-plane version of the exact problem the Ted backdoor hitting headlines this same week represents on the data-plane side: the device’s own reporting is the thing that got compromised, not just the traffic passing through it.

The smaller two

Two S/MIME decryption flaws in Secure Email, CVE-2026-20354 and CVE-2026-20355, both CVSS 5.9, let a machine-in-the-middle attacker recover plaintext from mail passing between gateways running AsyncOS 16.5.0 or earlier with S/MIME configured. And a phone denial-of-service bug, CVE-2026-20281, CVSS 7.5, affects Desk Phone 9800, IP Phone 7800/8800, and Video Phone 8875 devices registered to Unified Communications Manager with Web Access enabled, a setting that’s off by default. Neither is in the same category as the two above, but both patched the same day and both are worth a line in whoever’s tracking this release internally.

What to actually do

If you run Nexus 9000 gear, check show module against the ten affected product IDs above before anything else, and if you’re on one of them, get an iACL in place blocking 43210/43211 today rather than waiting on the Software Checker to confirm a fixed release. If you run IOS XR anywhere, don’t wait for a CVSS score to decide urgency, since a workaround doesn’t exist for any of these seven regardless of severity. Pull your release against Cisco’s SMU table and either apply the SMU or plan the upgrade, whichever path is shorter for your fleet.

Sources: Cisco Security Advisory: Cisco Nexus 9000 Series Switches Silicon One Remote Code Execution Vulnerability · Cisco Security Advisory: Cisco IOS XR Software Security Hardening Release: September 2026 · The Hacker News: Critical Cisco Nexus 9000 Flaw Lets Unauthenticated Remote Attackers Run Code as Root · Sygnia: Fire Ant Evolves From Hypervisors to Trusted Infrastructure