Severity Daily

IT and AI security incidents, checked against the primary source

Tag: CVE-2026-20212

  • Four deadlines expire Saturday, which is why the day’s four fresh 9.8s are not the lead

    Four deadlines expire Saturday, which is why the day’s four fresh 9.8s are not the lead

    Four items published today carry a federal remediation deadline of Saturday, September 5. That is two days out, and it is the day’s lead. It outranks the four fresh 9.8s that landed alongside it, because a 9.8 with no confirmed exploitation and no clock attached is a patch you schedule, and a Saturday deadline is a patch somebody has to be at a keyboard for. Two of those 9.8s do not have a release number to install anyway.

    The thread is real, and it is CISA’s. Six of today’s ten stories trace back to one batch of Known Exploited Vulnerabilities additions made on September 2 — four due September 5, two due September 16. Running underneath it is the same problem in three of the four Saturday items: the authoritative record does not cleanly say what to install.

    Deal with SonicWall’s SMA1000 pair first. It is an internet-facing access appliance, it is the third zero-day pair on that product, and the CVE records SonicWall assigned itself list affected builds without naming a fixed one — two days before the deadline. Then JFrog Artifactory, where CISA’s listing is the first government confirmation that the unauthenticated administrative bypass is being exploited, and where the medium-severity Artifactory CVE listed six days earlier is now due five days later than the critical one. Then Sangoma’s Switchvox, where the release notes mark the fix for both cloud and on-premises but the only CPE on the record covers on-premises, so an agency running the cloud edition cannot tell from the record whether it is in scope. Then Kestra, the one of the four whose difficulty is a label rather than a version: CISA files it as OS command injection, and what an attacker actually reaches is a filter asking whether a request path ends with the word configs.

    The two September 16 items are lower on the clock and higher on reach. Starlette’s BadHost is a 6.5 by three independent scorers, which is the number most likely to send a KEV entry to the bottom of a patch queue — and Starlette is what FastAPI is built on, so the inventory question is not “do we run Starlette” but “what did we build on FastAPI.” LiteLLM is the narrower one, and the sharper bug: the MCP endpoint answered a failed key check by substituting an empty authorization object and letting the request through.

    After the clocked items, the 9.8s. Cisco’s Nexus 9000 Silicon One root RCE names ten switch SKUs and points its Fixed Software section at an interactive tool instead of a release number; the record has no CPE data at all. Cisco’s IOS XR hardening release, published the same afternoon, packages an internal audit into seven CVEs across every release, two of them 9.8, with one CVE ID standing for thirteen distinct weakness types. That is Cisco twice in one day, both times with a remediation story that is harder to read than the vulnerability. Delinea’s Secret Server takes a 9.8 at the FIDO2 registration step in a privileged access manager, and NVD deferred the record the following day, leaving it with no machine-matchable version data. And thirteen Craft CMS CVEs arrived from two CNAs, neither of them Craft, onto advisories that say “No known CVE” — with one advisory drawing two IDs and one record carrying a description for a different bug.

    What is still open. SonicWall has not named a fixed build for either SMA1000 CVE with the deadline on Saturday. JFrog has published no in-the-wild statement of its own; the government confirmed exploitation before the vendor did. Sangoma has not resolved the cloud-versus-on-premises scope on the record itself. Cisco’s first IOS XR fix that is not a software maintenance update has not shipped, and it revised the fixed-release list within six hours of publishing it. The Delinea record is deferred, so scanners matching on CPE will not flag an affected install.

  • Cisco scores the Nexus 9000 Silicon One root RCE at 9.8, and neither the advisory nor the CVE record names a fixed release

    Cisco scores the Nexus 9000 Silicon One root RCE at 9.8, and neither the advisory nor the CVE record names a fixed release

    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.