CVE-2026-20212: Cisco Nexus 9000 with Silicon One ASIC Exposed…

Cisco disclosed a critical vulnerability in Nexus 9000 Series Switches equipped with Silicon One ASIC. CVE-2026-20212 carries a CVSS 9.8 score and allows an unauthenticated remote attacker to execute code as root via two exposed TCP ports in the default Layer 3 VRF.

Cisco disclosed a critical vulnerability on September 2, 2026, in Nexus 9000 Series Switches equipped with Silicon One ASIC. CVE-2026-20212, rated CVSS 9.8, allows an unauthenticated remote attacker to execute code with root privileges by exploiting two TCP ports exposed in the default Layer 3 VRF. The flaw poses an immediate risk to core datacenter infrastructure, where these switches handle spine-leaf traffic for enterprise and cloud provider networks.

Key Takeaways

CVE-2026-20212 scores CVSS 9.8: maximum severity for a pre-authentication remote attack that completely bypasses access controls.
TCP ports 43210 and 43211, normally hidden, are accessible in the default Layer 3 VRF due to non-restrictive IP address binding (CWE-1327).
Crafted input sent to these ports is executed as code with root privileges by the S1HAL process, with potential device crash and reload.
Remediation does not follow a static release table; it requires the Cisco Software Checker, and temporary mitigations have model- and version-specific support limits.

How the Attack Vector Works

The vulnerability resides in the Silicon One Hardware Abstraction Layer (S1HAL), the component that abstracts interaction between the NX-OS operating system and the Silicon One chipset. The issue is classified as CWE-1327: binding to an unrestricted IP address. The management service associated with S1HAL binds to a broad IP address — typically 0.0.0.0 or equivalent — instead of an isolated management interface.

This architectural choice exposes TCP ports 43210 and 43211 within the default Layer 3 VRF, the standard routing context where data traffic flows. An attacker with IP connectivity to the device can establish a connection to these ports without prior authentication. Crafted input sent through the channel is processed by S1HAL and executed with root privileges, the highest level in the NX-OS operating system.

The Cisco advisory documents that exploitation can cause two chained effects: an abnormal termination of the S1HAL process and a subsequent device reload. This implies not only compromise but also service disruption, impacting infrastructure that often handles hundreds of terabits per second.

Why the Patch Isn't in a Static Table

Cisco structured the disclosure using a model that its VP of Information Security, Russ Smoak, described as designed to close the window between disclosure and exploitation. The advisory release on September 2, 2026, is synchronized with the availability of fixed software, but not in a fixed table format. The 10 affected product identifiers (PIDs) — verifiable with the show module command — correspond to Nexus 9000 models with Silicon One ASIC, but the specific release that fixes each one depends on dynamic parameters.

To identify the correct fix, operations teams must use the Cisco Software Checker, a tool that cross-references PID, current NX-OS version, and target release. This approach introduces operational latency: the tool requires access to the Cisco portal, connection to external infrastructure, and manual verification for each device. In environments with hundreds of switches, this dependency on a vendor-specific tool complicates change management planning, especially within already saturated maintenance windows.

According to cross-verification by the CVE Program on September 3, 2026, cited by The Hacker News, affected releases number 45, spanning NX-OS 10.3(1) through 10.6(3s). The wide range reflects the temporal distribution of the Silicon One ASIC across multiple firmware generations.

Temporary Mitigations and Their Limits

The Cisco advisory identifies two temporary countermeasures: infrastructure ACLs (iACLs) that block traffic to ports 43210 and 43211, and the Live Protect shield lp00031. Both present significant operational constraints.

iACLs require manual application on each device and presuppose knowledge of the routing topology to avoid unintended blocks. The Live Protect shield lp00031 is available only for NX-OS 10.6(3) and 10.6(3s), excluding earlier releases that comprise the majority of the installed base. Additionally, the mechanism is not supported on Nexus 9804 and 9808 models, two high-end modular chassis commonly deployed in large-scale core networks.

This fragmentation of mitigative support means many teams lack an immediately applicable universal workaround. Removing the temporary protection and upgrading to a fixed release remain the only definitive path, but the dependency on the Software Checker introduces an organizational bottleneck that cannot be resolved with internal automation.

Immediate Actions

Immediately verify the presence of Silicon One ASIC with the show module command on every Nexus 9000; the 10 affected PIDs are listed in Cisco advisory cisco-sa-n9k-s1-rce-EH8dEtr.
Consult the Cisco Software Checker to identify the specific fixed release for each PID and installed NX-OS version, without assuming a single firmware covers all devices.
Apply iACLs blocking inbound traffic to TCP 43210 and 43211 on all interfaces of the default Layer 3 VRF, first verifying no functional dependencies exist on these ports.
Evaluate enabling the Live Protect shield lp00031 only for devices on NX-OS 10.6(3) or 10.6(3s) that are not Nexus 9804/9808 models, recognizing this protection is partial and transient.

Context of Cisco's September Disclosure

The September 2, 2026 disclosure is part of a broader batch of Cisco advisories that includes hardening releases for IOS XR and IOS XE, but the Nexus 9000 vulnerability stands out for its severity and vector simplicity. Discovery during a TAC support case — not by an external researcher or bug bounty — suggests the defect passed through multiple release cycles without internal detection, despite the exposure of TCP ports in a data VRF representing a known risk pattern.

Cisco states it is not aware of malicious use at the time of disclosure. This absence of confirmed exploitation does not reduce urgency: the pre-authentication nature of the vector, the criticality of the target — core datacenter switches — and the publicity of the disclosure create a window of opportunity measured in days, not weeks. Russ Smoak's quote about the goal of closing the disclosure-exploitation window takes on concrete operational significance here: teams have limited time to complete inventory of affected PIDs, navigate the Software Checker, and plan upgrades before exploitation capability spreads.

The remediation structure, with its dependency on an external tool and partial mitigations, reflects growing tension in the infrastructure vendor security supply chain: the complexity of the installed base — 45 releases, 10 PIDs, discontinuous mitigative support — shifts the decision burden to operations teams, who must now manage not only the vulnerability but the uncertainty of which patch applies to which device.

"A vulnerability in the Silicon One integration for Cisco Nexus 9000 Series Switches could allow an unauthenticated, remote attacker to execute code with root privileges" — Cisco Security Advisory cisco-sa-n9k-s1-rce-EH8dEtr

FAQ

Why can't I just consult a fixed release table?
The Cisco advisory does not provide a static PID-release matrix; the correct fix varies by hardware and firmware combination. The Software Checker is the only authorized channel to determine the target version.

Are Nexus 9000s in ACI mode vulnerable?
No. The Cisco advisory explicitly states that devices in ACI mode, as well as Nexus 3000, Nexus 7000, and UCS X-Series, are not affected by CVE-2026-20212.

Is the Live Protect shield sufficient as long-term protection?
No. The lp00031 shield is a temporary mitigation with support limited to specific NX-OS versions and models; definitive remediation requires upgrading to the release indicated by the Software Checker.

Information verified against cited sources and current as of publication.

Sources

Sources and references

Get DeafLetter