Article

    Cyber News / Article / Critical Cisco Nexus 9000 Flaw Lets Unauthenticated Remote Attackers Run Code as Root

    Critical Cisco Nexus 9000 Flaw Lets Unauthenticated Remote Attackers Run Code as Root
    in
    [email protected] (The Hacker News)-8 days ago

    Critical Cisco Nexus 9000 Flaw Lets Unauthenticated Remote Attackers Run Code as Root

    Cisco has released patches to address a critical security flaw affecting 10 Silicon One-based Nexus 9000 switches that could allow an unauthenticated, remote attacker to execute code as root, alongside an IOS XR hardening release bundling 7 umbrella CVEs, 2 of which are rated 9.8, with no workaround for any IOS XR version.

    The Nexus vulnerability, tracked asCVE-2026-20212(CVSS score: 9.8), is a case of binding to an unrestricted IP address that leaves TCP ports 43210 and 43211 reachable in the default Layer 3 virtual routing and forwarding (VRF) instance.

    An attacker who can reach a switch's address on either port can connect directly to the service. Crafted input sent to that service is then executed as code with root privileges. An exploitation attempt can also crash the S1HAL process and reload the device.

    Cisco said it's not aware of any malicious use of the flaw as of its September 2 disclosure. It has published no fixed-release table and directs customers to its Software Checker, with an infrastructure access control list (iACL) blocking the two ports and a temporary Live Protect shield as stopgaps.

    Cisco tells IOS XR customers, including those on IOS XR7 (LNT), to upgrade to a release that includes software maintenance updates (SMUs), then apply them.

    "At the same time, the window between disclosure and exploitation has effectively closed," Russ Smoak, vice president of information security at Cisco, said ina June blog postannouncing the twice-monthly disclosure model that groups internally found bugs into umbrella CVEs.

    Cisco lists the following affected product identifiers (PIDs) inits Nexus 9000 advisory, checkable against the output of the show module command -

    Other Nexus 9000 models, Nexus 9000 fabric switches running in Application Centric Infrastructure (ACI) mode, and the Nexus 3000 and 7000 lines are unaffected.

    The Hacker News confirmed viathe CVE Program's recordon September 3 that Cisco lists 45 NX-OS releases, from 10.3(1) through 10.6(3s), as affected, a range the advisory itself leaves to the Software Checker.

    Until a fixed release is confirmed, Cisco offers the following -

    The IOS XR release assigns one CVE to each Common Weakness Enumeration (CWE) bucket of fixed bugs and scores it at the most severe defect in that bucket, per the rules inits risk-based disclosure FAQ.

    CVE-2026-20274, which covers memory-safety and resource-lifetime bugs, andCVE-2026-20279, which covers access-control bugs including missing authentication for critical functions and improper certificate validation, each carry a 9.8 ceiling inthe record for CVE-2026-20274andthat for CVE-2026-20279.

    The remaining five, CVE-2026-20275 through 20278 and CVE-2026-20280, top out between 8.2 and 8.8.

    The vulnerabilities affect all releases regardless of device configuration,the IOS XR hardening advisorysaid.

    The XR7 (LNT) platforms, which include the Cisco 8000 Series, NCS 1010, NCS 540L, and NCS 5700 Series, have a dedicated SMU that applies across all releases.

    Cisco said there may be "approximately 16 SMUs available for each release," that future releases 26.2.2 and 26.3.1 will be the first fixed releases needing no SMUs, and that customers running a release outside its table should open a Technical Assistance Center (TAC) case.

    SMUs are available for the following releases -

    SMUs are listed as future releases for 24.1.2, 24.3.2, 25.1.2, and 25.2.2.

    The advisory lists the following SMU identifiers by functional area -

    CSCwv19171 applies to both IS-IS and OSPF, Cisco noted.

    The Hacker News cross-checked the seven CVE records against the advisory on September 3 and found that, of the 111 IOS XR releases Cisco lists as affected, 14 have SMUs available today, four are awaiting SMUs, and 93 must first be upgraded before a fix can be applied.

    The September 2 drop is the third scheduled hardening release in 30 days, followingthe first hardening dropon August 5, which deliveredthe IOS XE hardening releaseanda Catalyst SD-WAN release, andtwo CVSS 10.0 releasesfor Crosswork and Secure Workloadtwo weeks later.

    Separately, two publicly disclosed Secure/Multipurpose Internet Mail Extensions (S/MIME) decryption flaws in Secure Email, CVE-2026-20354 and CVE-2026-20355 (CVSS scores: 5.9), allow a machine-in-the-middle attacker to recover plaintext from mail passing between gateways running AsyncOS 16.5.0 or earlier with S/MIME configured, Cisco said inthe Secure Email advisory. Fixed releases for that pair are stated only in the bug records.

    The same day's advisories also fixeda phone denial-of-service bug, CVE-2026-20281 (CVSS score: 7.5), in Desk Phone 9800, IP Phone 7800 and 8800, and Video Phone 8875 devices registered to Unified Communications Manager with Web Access enabled, a setting that's off by default. Fixes arrive in SIP Software 5.0(1), 14.4(1)SR3, 14.4(1)SR4, or 11.0(6)SR8 depending on the model.

    The development comes six days after Sygnia said the China-nexus threat actor Fire Ant,first documented in 2025, ran purpose-builtimplants on IOS XR routersthat suppressed syslog delivery, filtered show command output, and supported a hidden Generic Routing Encapsulation (GRE) tunnel.

    The actor also captured packets from routers, uploaded them to external FTP servers, and made connection attempts and port scans against connected systems associated with critical infrastructure.

    The investigation began with a tunnel interface active on a router with no running configuration or commit history to explain it, which, Sygnia said inits Fire Ant report, suggested the device's operational state "could no longer be trusted to match the configuration and audit records."

    Sygnia did not identify how the actor first gained access to the routers or name any vulnerability.

    Original source