Cisco Nexus 9000 CVE-2026-20212 Shows Your Running Config Is Not an Inventory

Sep 7, 2026 · 9 min read cybersecuritycloudsecuritynetwork-securityciscovulnerability-management

Almost every network security programme rests on an assumption so basic that nobody writes it down: that the device’s configuration is an accurate description of the device. You collect running-configs, you diff them, you audit them, you feed them into a CMDB, and you treat the result as inventory. The whole edifice — segmentation review, exposure analysis, change control — is built on the idea that what the box is configured to do and what the box is actually doing are the same thing.

In a single week, three unrelated disclosures pulled that assumption apart from three different directions. Network device configuration drift detection stopped being a hygiene concern and became a control gap.

The bug that is not in your config

Cisco disclosed CVE-2026-20212 on 2 September 2026, carrying a CVSS score of 9.8. The technical class is the interesting part: it is a case of binding to an unrestricted IP address — CWE-1327 — that leaves TCP ports 43210 and 43211 reachable in the default Layer 3 VRF instance.

An unauthenticated attacker who can reach an affected switch on either port connects directly to the service. Crafted input sent to it is then executed as code with root privileges. No credentials, no user interaction, low attack complexity. A failed attempt is not harmless either: exploitation can crash the S1HAL process and reload the device, turning a compromise attempt into an outage.

The affected population is narrow and specific. Ten Silicon One-based Nexus 9000 product IDs are listed, checkable against show module output: N9324C-SE1U, N9348Y2C6D-SE1U, N9364E-SG2-O, N9364E-SG2-Q, N9396T12C-SE1, N9348Y12C-SE1, N9396Y12C-SE1, N9336C-SE1, N9K-C9804 and N9K-C9808. Other Nexus 9000 models, Nexus 9000 fabric switches running in ACI mode, and the Nexus 3000 and 7000 lines are unaffected. Cisco stated it was not aware of any malicious use as of the 2 September disclosure.

Now note what a configuration audit would have found here. Nothing. No administrator enabled this listener. It does not appear in the running-config. There is no feature statement to grep for, no ACL that references it, no change ticket behind it. The service is bound in the default VRF because that is what the platform code does, and the only artefact of its existence is a socket in a listening state. A control that reads configuration cannot see a service that configuration never mentions.

This is why the routing context matters more than the port number. Most operators carry a mental model in which management-plane services live in a management VRF, reachable from a jump host, fenced off from the data path. That model is a design intention. CVE-2026-20212 is what it looks like when the implementation quietly disagrees with the design, and nothing in the toolchain is positioned to notice.

The advisory that will not tell you your version

The second crack appeared in the same 2 September drop. Alongside the Nexus bug, Cisco shipped an IOS XR hardening release bundling seven umbrella CVEs, two of which carry a 9.8 ceiling: CVE-2026-20274, covering memory-safety and resource-lifetime bugs, and CVE-2026-20279, covering access-control defects including missing authentication for critical functions and improper certificate validation. The remaining five top out between 8.2 and 8.8. These affect all releases regardless of device configuration, and there is no workaround for any version.

The scoring model is the part worth pausing on. Under Cisco’s risk-based disclosure rules, one CVE is assigned per Common Weakness Enumeration bucket and scored at the most severe defect in that bucket. This is a deliberate shift, announced by Cisco vice president of information security Russ Smoak in June alongside a move to twice-monthly disclosure that groups internally found bugs together — a response, he argued, to a disclosure-to-exploitation window that has effectively closed.

The operational consequence is that a CVE identifier no longer maps to a defect. Asking whether you are affected by CVE-2026-20279 has no single answer, because the identifier names a category. And for the Nexus vulnerability, Cisco published no fixed-release table at all, directing customers to its Software Checker instead. The Hacker News cross-checked the CVE Program record on 3 September and found Cisco listing 45 NX-OS releases as affected, from 10.3(1) through 10.6(3s) — a range the advisory itself leaves to the tool.

Vulnerability management pipelines are built around a tuple: CVE, affected version, fixed version. When the vendor stops emitting that tuple in machine-readable form, the pipeline does not fail loudly. It returns no findings. The same outlet’s cross-check of the IOS XR advisory found that of 111 affected releases, only 14 have software maintenance updates available today and four are awaiting them — 93 must be upgraded before a fix can even be applied.

The adversary editing what the device reports

The third crack is the one that should change how you read the first two. Six days before the Cisco drop, Sygnia published research on Fire Ant, a China-nexus threat actor running purpose-built implants on IOS XR routers.

This was not generic Linux tooling dropped on a network appliance. The malware interacted directly with IOS XR logging, command execution, routing, VRF resolution, AAA and Telnet-management functions. It embedded a modified syslog library that selectively suppressed log events containing the string Health, returning a success-like result without forwarding anything to the logging pipeline. It filtered show command output. It maintained a hidden GRE tunnel, established outbound Telnet connections to actor infrastructure, and supported interactive shell access with no logging at all. Captured packets were uploaded to external FTP servers, and the routers were used to port-scan connected critical infrastructure.

How was it found? An investigator noticed an active GRE tunnel interface on a router that no running configuration or commit history could explain. Sygnia’s conclusion is the sentence that ties this whole week together: the device’s operational state “could no longer be trusted to match the configuration and audit records.”

To be precise about what is and is not claimed here: Sygnia did not identify how Fire Ant first gained access and did not name any vulnerability. There is no evidence linking this campaign to CVE-2026-20212. The connection is structural, not causal — and that is what makes it worth acting on.

Impact assessment

Risk rating: Critical for organisations running affected Silicon One Nexus 9000 hardware, particularly in AI and high-performance data centre fabrics where these platforms concentrate.

The direct exposure is unauthenticated root on a switch that sits inside the trust boundary of everything it forwards. But the systemic impact is broader and harder to price. Three mechanisms now independently break the mapping between declared and actual device state:

Layer	Failure mode	What it defeats
Platform	Service bound in default VRF, absent from config	Config audit, segmentation review, CMDB
Vendor advisory	Umbrella CVEs, no fixed-release table	Automated vulnerability correlation
Adversary	Log suppression and `show` output filtering	Detection, forensic reconstruction

Any one of these is a manageable gap. Together they mean the three sources most teams rely on to answer “what is this device doing” — its config, its vendor’s advisory, and its own logs — can each be wrong at the same time, for unrelated reasons.

The CloudShieldSecure perspective

This is precisely the gap we built CloudShieldSecure to close. Exposure inventory in our model is not a periodic reconciliation of configuration files against a database. It answers a different question: which services are actually listening, in which routing context, reachable by whom — derived from observed state rather than declared state.

That distinction is not academic here. A configuration-derived inventory returns a clean result for CVE-2026-20212, because there is nothing in the configuration to find. An observation-derived inventory shows a listener on 43210 in the default VRF, in a routing context where no management-plane service should be answering, and it shows it before a CVE identifier exists to name it. The same discipline is what surfaces a GRE tunnel that no commit history explains.

The broader principle we work from at CloudKonsult is that controls keyed to identifiers — CVE numbers, CVSS scores, KEV entries — inherit the failure modes of the identifier system. Controls keyed to observed reachability do not. When vendors restructure how they issue CVEs, the first category degrades silently and the second keeps working.

Recommended actions

Identify affected hardware now. Run show module across your Nexus 9000 estate and match against the ten listed PIDs. Do not assume model-family exclusion — ACI-mode fabric switches and the 3000/7000 lines are genuinely unaffected, but Silicon One presence is the deciding factor.
Apply an infrastructure ACL as the immediate control. Permit only required management and control-plane traffic, or explicitly deny TCP packets to locally configured switch IP addresses on destination ports 43210 and 43211. Prove it in a test environment first.
Upgrade to the release named by Cisco’s Software Checker. There is no static fixed-release table to work from; the tool is the authoritative source.
Treat Live Protect shield lp00031 as a stopgap, not a fix. It is supported only on NX-OS 10.6(3), and on 10.6(3s) for the two Smart Switches via a second package. It is unsupported on the Nexus 9804 and 9808, requires SSH, Telnet or NX-API access, and its operational mode transitions to N/A on upgrade to 10.6(4) or higher.
Audit listening sockets by VRF, not by config. For every network device class in your estate, enumerate what is actually bound and in which routing context. Treat any listener in the default VRF that the configuration does not explain as a finding.
Add a declared-versus-observed reconciliation to your detection logic. Interfaces, tunnels and routes present in operational state but absent from running-config and commit history are a high-fidelity signal — it is exactly what surfaced Fire Ant.
Re-check your vulnerability pipeline against umbrella CVEs. If your tooling silently returns no findings when a vendor omits a fixed-release table, you have a coverage gap that will widen as more vendors adopt grouped disclosure.

Sources and references

Assess your security posture today

CloudShield Secure scans, validates, and prioritises threats across your entire attack surface.

Explore CloudShield Secure →