Cisco’s September 2 advisory scores CVE-2026-20212 at 9.8 and names ten switch SKUs, but its Fixed Software section points at an interactive tool instead of a release number, and the CVE record has no CPE data at all.
What happened
Cisco published advisory cisco-sa-n9k-s1-rce-EH8dEtr on September 2, 2026, at version 1.0 and marked Final. The description, identical in the advisory and the CVE record: “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. This vulnerability exists because TCP ports 43210 and 43211 are accessible in the default Layer 3 (L3) virtual routing and forwarding (VRF).”
Cisco PSIRT scored it CVSS 3.1 base 9.8 with the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Network vector, low complexity, no privileges, no user interaction, total impact on all three properties. The weakness class is CWE-1327, binding to an unrestricted IP address — which is the accurate name for what happened here. Two ports belonging to the ASIC integration layer are listening in the VRF that carries ordinary routed traffic.
The scope is narrower than the product name suggests, and this is the part most coverage has flattened. Cisco’s wording: “This vulnerability affects Cisco Nexus 9000 Series Switches if they include a Silicon One ASIC.” The advisory names ten identifiers — N9324C-SE1U, N9348Y2C6D-SE1U, N9364E-SG2-O, N9364E-SG2-Q, N9396T12C-SE1, N9348Y12C-SE1, N9396Y12C-SE1, N9336C-SE1, N9K-C9804, and N9K-C9808 — and its Products Confirmed Not Vulnerable section lists most of the rest of the Nexus 9000 line alongside Nexus 3000 and 7000 switches, MDS 9000 directors, Firepower appliances, and UCS fabric interconnects.
Cisco PSIRT “is not aware of any public announcements or malicious use of the vulnerability.” The CVE is not in the KEV catalog and carries no federal deadline. The credit line is unusual: “This vulnerability was found during the resolution of a Cisco Technical Assistance Center (TAC) support case.” Not a researcher, not a bounty submission — a customer had an operational problem and this turned up while Cisco fixed it.
There is a workaround, quoted in full: “To prevent remote exploitation of this vulnerability, use infrastructure access control lists (iACLs) to allow only required management and control plane traffic that is destined to the affected device. Alternatively, the iACLs may be used to explicitly deny all TCP packets that are destined to a locally configured IP address with a destination port of 43210 or 43211.” Cisco has also released what it calls a Live Protect shield for CVE-2026-20212 as a temporary mitigation.
Nobody has published a version number
Here is the gap. The advisory’s Fixed Software section names no release. It says: “To help customers determine their exposure to vulnerabilities in Cisco NX-OS Software, Cisco provides the Cisco Software Checker,” and directs readers there. The Software Checker is an interactive form — you enter your platform and running release and it returns an answer for one device at a time.
The CVE record does not fill the gap either. NVD published CVE-2026-20212 at 5:17 p.m. UTC on September 2 and last modified it at 1:04 p.m. UTC on September 3. Its vulnStatus is still Awaiting Analysis, and it has no configurations section — no CPE strings of any kind, confirmed on two retrievals with different query forms. There is no hardware CPE naming a Silicon One switch, because there is no CPE at all. The CNA data gives an affected range across NX-OS 10.3.1 through 10.6.3 and nothing about the ASIC.
So for the first day of this advisory’s life, an organization with an automated vulnerability pipeline could get exactly nothing from it. Scanners match on CPE. There is no CPE. Configuration-management tooling matches on fixed version strings. There is no published fixed version string. The only two paths to an answer are a human reading a ten-item SKU list against an inventory, and a human typing release numbers into a web form.
Why it matters
The absent fixed-version table is the more consequential of the two problems, because it converts a patchable 9.8 into a manual audit. Cisco’s Software Checker is a good tool and it exists for a real reason: NX-OS has many trains and the first-fixed release differs across them, so a static table in the advisory would be long and would go stale. But the tradeoff has a cost that lands entirely on the customer, and it lands hardest on exactly the shops that have done the work to automate. A team that can answer “which of my devices are below the fixed release” in thirty seconds for a Fortinet advisory cannot answer it at all here, and has to fall back to the same spreadsheet everyone used in 2012.
The CPE absence compounds it rather than duplicating it. A CPE for this vulnerability would also be awkward — the correct one would have to combine an NX-OS software range with a hardware model list, which is the kind of composite NVD represents poorly and which almost every scanner then flattens back to the software range. That flattening is its own hazard: a version-only match on NX-OS 10.3 through 10.6 would flag every Nexus 9000 in the fleet, including the many models Cisco explicitly confirms are not vulnerable. Under-matching and over-matching are both wrong, and right now the record does neither because it does nothing.
The scope point deserves its own paragraph because the headlines have not carried it. “Critical Cisco Nexus 9000 flaw” describes a product family with a very large installed base. Cisco’s advisory describes ten SKUs sharing one ASIC family, and takes the trouble to enumerate what is not affected. An operator who reads the headline books an emergency change window for a fleet; an operator who reads the advisory checks a model list and discovers, in many environments, that the answer is none. Getting this wrong in the alarming direction is not harmless — it spends maintenance capital that the next advisory will need, and it teaches an organization to discount Cisco criticals.
Last, the discovery path is worth noting for what it implies about duration. This was not found by someone auditing the Silicon One integration; it was found while resolving a support case. Ports bound in the default VRF do not announce themselves, and nothing in the advisory says when the binding was introduced. The affected software range runs from 10.3.1 to 10.6.3, which is a wide span of releases. That is not evidence of exploitation — Cisco says it has none — but it is a reason to treat the iACL as worth applying now even if the upgrade waits for a window.
The advisory came out in a bundle. Cisco’s own advance notification for September 2, 2026 said the batch would contain four advisories: two critical at 9.8, one high at 7.5, and one medium at 5.9, and that “hardening releases and other security advisories are scheduled to publish on the first and third Wednesday of each month.” SecurityWeek reports the other critical pair as IOS XR issues, CVE-2026-20274 and CVE-2026-20279, and reports a separate set of publicly disclosed, unpatched S/MIME flaws in Cisco Secure Email. Severity Daily has not read those advisories against their primary sources and is not reporting their details here.
What to do
- First determine whether you own an affected switch at all. Only Nexus 9000 models with a Silicon One ASIC are affected: the ten identifiers listed above. Cisco’s Products Confirmed Not Vulnerable section covers the rest of the line.
- Run the Cisco Software Checker for your NX-OS train. There is no fixed release named in the advisory text and no CPE data in the CVE record, so this is currently the only way to get a target version.
- Apply the iACL now, whether or not you upgrade this week. Deny TCP to ports 43210 and 43211 destined for locally configured addresses, or restrict management and control-plane traffic generally. This is Cisco’s own wording and it removes the remote path.
- Consider the Live Protect shield as a stopgap on devices you cannot reload quickly. Cisco describes it as temporary mitigation, not a fix.
- Do not treat this as an emergency on the strength of the 9.8 alone. There is no known exploitation, no public exploit, no KEV listing, and no federal deadline. The severity is real and the urgency is a function of how reachable your routed interfaces are.
Sourcing note
The advisory text, the CVSS vector, the affected SKU list, the Products Confirmed Not Vulnerable section, the workaround wording, the exploitation statement, and the TAC credit were read from Cisco’s advisory cisco-sa-n9k-s1-rce-EH8dEtr, fetched twice with different prompts; the Fixed Software section’s deferral to the Software Checker was consistent across both, and no fixed release number appeared in either retrieval. The publication date, description, CWE, CVSS source, vulnStatus, and the absence of a configurations section were read from the NVD API record (lastModified 2026-09-03T13:04:38.177), also retrieved twice with different query forms; the absence of CPE data was confirmed on both.
The bundle composition comes from Cisco’s own advance notification page. The identification of the other advisories in that bundle comes from SecurityWeek and has not been checked against the individual Cisco advisories, which is why no details of them appear above. Unresolved: what the first fixed NX-OS release is on each affected train, and when the port binding was introduced. Neither is answerable from a public static source today. Cisco may add a fixed-release table in a later advisory revision; this page reflects version 1.0.