Severity Daily

IT and AI security incidents, checked against the primary source

Tag: Cisco

  • 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’s IOS XR hardening release groups an internal audit into seven CVEs across every release, and the first fix that is not an SMU has not shipped

    Cisco’s IOS XR hardening release groups an internal audit into seven CVEs across every release, and the first fix that is not an SMU has not shipped

    Two of the seven are scored 9.8, one CVE ID stands for thirteen distinct weakness types, and Cisco revised the fixed-release list within six hours of publishing it.

    What happened

    Cisco published advisory cisco-sa-hardening-iosxr-qg64NcM, “Cisco IOS XR Software Security Hardening Release: September 2026,” on September 2, 2026 at 4:00 p.m. GMT. It carries seven CVEs, two of them scored 9.8, and states that they “affect all releases of Cisco IOS XR Software, including Cisco IOS XR7 (LNT) Software, regardless of device configuration.”

    Cisco is clear about where the findings came from: “As part of Cisco’s ongoing commitment to proactive security and product quality, the Cisco IOS XR Software engineering team has conducted a comprehensive internal security review. This review resulted in software hardening releases that address multiple internally discovered vulnerabilities. These vulnerabilities were found during internal testing and are not known to be actively exploited.” Under exploitation: “The Cisco PSIRT is not aware of any public announcements or malicious use of the vulnerabilities that are described in this advisory.”

    The seven, with the scores Cisco assigned:

    • CVE-2026-20274 — 9.8 — CWE-664, improper control of a resource through its lifetime
    • CVE-2026-20279 — 9.8 — CWE-284, improper access control
    • CVE-2026-20275 — 8.8 — CWE-682, incorrect calculation
    • CVE-2026-20278 — 8.8 — CWE-707, improper neutralization
    • CVE-2026-20280 — 8.8 — CWE-703, improper check or handling of exceptional conditions
    • CVE-2026-20276 — 8.6 — CWE-691, insufficient control flow management
    • CVE-2026-20277 — 8.2 — CWE-693, protection mechanism failure

    Both 9.8s carry the same vector, CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H — network reachable, no privileges, no user interaction, full compromise of confidentiality, integrity, and availability.

    None of the seven describes a single defect. Each is a container for a class, and Cisco’s own CVE record says so in the plural: “The vulnerabilities tracked by CVE-2026-20274 are related to improper resource control issues that are grouped under the Common Weakness Enumeration (CWE) CWE-664.” The advisory then lists what the container holds. CVE-2026-20274 “covers buffer copy without checking size of input, stack-based buffer overflow, heap-based buffer overflow, out-of-bounds read, use of externally-controlled format string, numeric truncation error, use after free, exposure of resource to wrong sphere, operation on a resource after expiration or release, allocation of resources without limits or throttling, out-of-bounds write, use of out-of-range pointer offset, and initialization of a resource with an insecure default.” Thirteen weakness types under one identifier. CVE-2026-20279, the other 9.8, “covers improper certificate validation, missing authentication for critical function, missing authorization, and incorrect authorization” — four more.

    Cisco’s CNA record enumerates 127 affected versions, from 6.5.25 through 26.2.101. On workarounds the advisory is one sentence: “There are no workarounds that address these vulnerabilities.”

    Remediation is Software Maintenance Updates. The advisory publishes two tables, one mapping software trains to available SMU releases and one mapping functional areas to SMU identifiers. Then: “Future Cisco IOS XR Software releases 26.2.2 and 26.3.1 will be the first fixed releases that will not require SMUs.” Both are future tense in Cisco’s own sentence. An operator who remediates by moving to a fixed release has no destination available today.

    The advisory has already been revised once. Its history shows version 1.0, “Initial public release,” and 1.1, “Removed end-of-life software,” against the Fixed Releases section, both dated the same day. Version 1.0 went out at 4:00 p.m. GMT and the page was last updated at 9:53 p.m. GMT, so the remediation section changed inside six hours. Cisco published the note but not the diff, and we cannot see version 1.0 to say which end-of-life trains came out.

    Why it matters

    The CVE identifier is the unit nearly every downstream system counts in. Scanners key on it, ticketing systems open one row per ID, SBOM tooling matches on it, the KEV catalog lists it, and BOD 26-04 derives a federal deadline from four binary variables attached to it. All of that machinery assumes an identifier maps to a defect. Here one maps to thirteen.

    The consequence is not obvious from a scanner row. “Patched CVE-2026-20274” can only mean that the full SMU set closed all thirteen classes on your platform, because there is no finer grain to report against. Nothing in the record says how many individual bugs were found, which of the thirteen applied to your hardware, or whether they sat in one subsystem or seven. A partial remediation and a complete one produce the same identifier and the same closed ticket.

    The score inherits the problem in the other direction. A 9.8 with AV:N/PR:N is the most severe thing the container holds, and it is now printed against everything in it. Cisco does not claim otherwise; the advisory is plain that these are groupings. But transparency at the source does not survive the trip. By the time the number reaches a risk register it is simply a 9.8 on a CVE.

    Then there is scope. “All releases … regardless of device configuration” removes the lever operators normally use to triage a platform advisory. The usual first question is whether the affected feature is enabled, and the usual answer spares most of the fleet. Cisco has answered it in advance, for every box: configuration does not matter. What remains is inventory, across 127 versions reaching back to 6.5.25.

    The comparison worth drawing is Cisco’s own, a month earlier. On August 5, 2026, the company published the same kind of advisory for a different operating system: “Cisco IOS XE Software Security Hardening Release: August 2026” — also seven CVEs, also grouped by weakness class, also from an internal review, also with no workarounds. The difference is the Fixed Software section. That advisory named first fixed releases, 17.9.10, 17.12.8, 17.15.6, 17.18.4, and 26.1.2, and they existed. An IOS XE operator could schedule a version upgrade. An IOS XR operator can schedule SMUs, or wait for a release Cisco has not shipped.

    That gap is a shape this publication has documented all week from another angle. Cisco’s other critical advisory from the same publication batch, the Nexus 9000 Silicon One root execution flaw at 9.8, names no fixed release at all. In each case the vulnerability information is published on schedule and the remediation information trails it. The advisory is the part that gets written first, and the part an operator actually needs — a build number they can put in a change ticket — arrives later, or arrives as a maintenance update that has to be assembled per functional area.

    None of this is an emergency and should not be written as one. Cisco says it is not aware of malicious use, and neither 9.8 is in the KEV catalog: two retrievals of NVD’s record for CVE-2026-20274, using different URL forms, both return no cisaExploitAdd, cisaActionDue, cisaVulnerabilityName, or cisaRequiredAction, at a lastModified of 2026-09-03T13:04:39.223 and a vulnStatus of “Awaiting Analysis.” There is no federal clock here — just a large, universal, unexploited exposure on infrastructure that gets patched in planned windows. The planning is the work.

    What to do

    Inventory IOS XR by train and build, not by platform family, and skip the exposure assessment — Cisco has said configuration does not narrow it. Every release is in scope, including IOS XR7 (LNT).

    Pull SMU identifiers from both tables, not one. The train table tells you which SMU release applies to your version; the functional-area table tells you which identifiers exist. A single update is unlikely to be the whole answer for a box running a broad feature set.

    If you read this advisory on September 2 and captured the fixed-release list, read it again. Version 1.1 removed end-of-life software from that section hours later. If your train is end-of-life, the coverage you noted may no longer be listed, and Cisco did not publish what changed.

    If your change process targets releases rather than maintenance updates, record 26.2.2 and 26.3.1 as the first non-SMU destinations and record that they are not available yet. That is a planning input, not a remediation. Do not wait for a workaround; the advisory states there is none.

    The lever you do control is reachability. Both 9.8s are AV:N, so exposure tracks who can reach these devices’ management and control planes. Restricting that reach does not close the flaws — it is what is available while the SMU work is scheduled.

    Sourcing note

    The advisory text, CVE list, scores, weakness groupings, workaround and exploitation statements, fixed-software wording, and revision history come from Cisco’s advisory page for cisco-sa-hardening-iosxr-qg64NcM, retrieved on September 3, 2026. Cisco is the CNA for all seven CVEs, so the descriptions and vectors quoted here are the vendor’s own text, taken from the CVE Program API for CVE-2026-20274 and CVE-2026-20279 and cross-checked against NVD. The 127-version count and the 6.5.25-through-26.2.101 range are from Cisco’s CNA record.

    The August IOS XE comparison is from Cisco advisory cisco-sa-hardening-iosxe-V8NMuMZJ, retrieved the same day; its fixed releases are reported as that advisory lists them, and we did not verify their availability on Cisco’s download site.

    The KEV absence was checked twice against NVD with different URL forms, per this newsroom’s rule that one fetch cannot establish that a record lacks a field. CISA’s catalog feed and alert pages return HTTP 403 to automated requests, so KEV status came through NVD, which republishes CISA’s fields verbatim and lags the catalog by hours.

    Unresolved: how many individual defects sit behind each identifier, which end-of-life trains left the Fixed Releases section between version 1.0 and version 1.1, and whether the CVE Program record for CVE-2026-20279, carrying a dateUpdated of 2026-09-03T03:56:30.714Z, changed substantively or administratively. We could not see the superseded version of either document.

  • 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.