A default bind on ten Silicon One Nexus 9000 switches exposes root over ports 43210 and 43211

The flaw traces to a default binding on an unrestricted IP address, which changes what remediation looks like compared with a memory-corruption bug. The service answers anything that can route to a switch address in the default Layer 3 VRF on either port ^[1]. Nothing authenticates, so crafted input goes straight to execution as root, and an attempt that fails takes down the S1HAL process and reloads the box ^[5]. The second outcome is the one that decides scan policy, because it means an unauthenticated probe can reload a device sitting in the data path.

The access list Cisco offers permits only required management and control-plane traffic, or explicitly denies TCP to a locally configured IP address on destination port 43210 or 43211, and Cisco says to prove it in a test environment first ^[7]. That is straightforward on a switch whose management addresses are already filtered. It is slower where the loopback or SVI is reachable from a broad internal range.

The temporary shield is narrower than it first reads. Live Protect lp00031 is supported on NX-OS 10.6(3), and on 10.6(3s) only through a second package covering the two Nexus Smart Switch identifiers. It does not support the Nexus 9804 or 9808, and it needs SSH, Telnet, or NX-API access to install ^[8]. Set that against the affected range: The Hacker News says the CVE Program record it checked on September 3 lists 45 NX-OS releases, 10.3(1) through 10.6(3s), as affected ^[14]. Only two of those 45 have a shield option, even counting 10.6(3s) generously, leaving the remaining 43 without coverage ^[17]. Two of the ten affected product identifiers are chassis with no shield at all ^[16].

The nearest thing to a fixed release in the published material is indirect. The shield's release notes say its operational mode transitions to N/A on upgrade to NX-OS 10.6(4) or higher ^[9]. That points at a target version, but the release note lacks the specificity of a fix table, and Cisco's advisory still routes release questions to the Software Checker ^[3].

Scope limits are worth stating plainly. Other Nexus 9000 models, Nexus 9000 fabric switches running in ACI mode, and the Nexus 3000 and 7000 lines are unaffected ^[10]. The check is show module against the ten listed identifiers ^[6].

The IOS XR half of the same disclosure is a separate job: seven umbrella CVEs, two of them at 9.8, affecting all releases regardless of device configuration, with no workaround for any version ^[4]. Cisco's route is to upgrade to a release carrying software maintenance updates and then apply them, roughly 16 per release, with 26.2.2 and 26.3.1 named as the first fixed releases needing none and anything outside the table going to a TAC case ^[11]. Russ Smoak, Cisco's vice president of information security, wrote in June that "the window between disclosure and exploitation has effectively closed" when he announced the twice-monthly model that groups internally found bugs into umbrella CVEs ^[15]. The XR7 (LNT) platforms, including the Cisco 8000 Series, NCS 1010, NCS 540L, and NCS 5700 Series, get one SMU that applies across all releases ^[13].