CVE-2026-20212: Cisco Nexus 9000 RCE Flaw

Cisco has disclosed a critical vulnerability, CVE-2026-20212, in the Silicon One integration used by certain Nexus 9000 switches. The flaw allows an unauthenticated remote attacker who can access the affected service to execute code with root privileges.

The vendor released its advisory on September 2, 2026, along with fixed software, stating that it was not aware of any public exploit code or malicious use at the time of publication. Teams running affected Nexus 9000 hardware should confirm exposure and prioritize patching.

What Is CVE-2026-20212?

CVE-2026-20212 (CVSS 9.8) is tied to the Silicon One hardware integration on select Nexus 9000 platforms and stems from CWE-1327, binding to an unrestricted IP address. Cisco says the relevant services listen on TCP ports 43210 and 43211 in the default Layer 3 VRF; a remote attacker able to reach those ports can send crafted input that executes as code with root privileges. Exploitation can also crash the S1HAL process and cause the switch to reload.

What Products Are Affected?

The following Cisco-listed product identifiers contain the affected Silicon One ASIC:

• N9324C-SE1U
• N9348Y2C6D-SE1U
• N9364E-SG2-O
• N9364E-SG2-Q
• N9396T12C-SE1
• N9348Y12C-SE1
• N9396Y12C-SE1
• N9336C-SE1
• N9K-C9804
• N9K-C9808

Cisco says Nexus 9000 models outside this list, Nexus 9000 fabric switches in ACI mode, Nexus 3000 switches, and Nexus 7000 switches are not affected. Organizations should still verify these exclusions against their own inventory using the Cisco Software Checker, which identifies affected releases and the corresponding fixed software for a given device.

What Is the Risk?

Reachability, not just hardware model, determines actual exposure. An attacker needs network access to the affected ports, so segmentation, access control lists, and management-plane design materially change a device’s risk profile. A switch unreachable from untrusted networks carries a different exposure than one with broader connectivity.

Cisco’s advisory does not currently describe public exploit code, and no malicious use has been identified at the time of disclosure. Available sources also do not establish how many affected devices are reachable from untrusted networks.

What Are the Signs of Compromise?

An S1HAL crash or unexpected device reload is a possible consequence of exploitation, not a unique detection signal on its own, so weigh it alongside other evidence. Consider monitoring for:

• Authentication anomalies or unexplained management activity
• Unexpected configuration changes on affected switches
• S1HAL process crashes or unplanned device reloads
• Traffic to TCP ports 43210 or 43211 from unexpected sources

Cisco has published Snort rule 67005 for vendor-supported detection. Treat any single alert as an investigation trigger, and correlate it with configuration differences, access-control changes, and maintenance records rather than treating it as confirmation of compromise.

Since exposure often comes down to what an organization’s network actually looks like from the outside, and it can be difficult to confirm which switches are reachable from untrusted paths without dedicated visibility, SOCRadar’s Attack Surface Management module helps map internet- and network-facing infrastructure to flag unexpectedly exposed devices, while the Cyber Threat Intelligence module tracks vulnerability intelligence and exploitation trends for issues like CVE-2026-20212 as they develop.

How Should Defenders Respond?

Immediate:

• Inventory Nexus 9000 switches, record product identifiers, and confirm running NX-OS releases against Cisco’s Software Checker.
• Apply Cisco’s fixed software to every affected device, and record the change in maintenance documentation.
• Restrict reachability to TCP ports 43210 and 43211 to only required management and control-plane traffic.

While patching is scheduled:

• Apply Cisco’s recommended port-specific controls or its Live Protect shield as temporary risk reduction, and test for effects on network functionality before relying on them.
• If a vulnerable switch was reachable from an untrusted network, preserve logs and compare its configuration against approved records as an investigation trigger.
• After upgrading or mitigating, validate routing, authentication, access controls, and management-plane behavior, including any reloads or service interruptions.

Cisco’s fixed software remains the primary remediation; temporary controls reduce risk while upgrades are scheduled but should not replace patching.