SAN JOSE, 22 AUG 2026 — Cisco published advisories on 19 August covering nine vulnerabilities in Crosswork and Secure Workload, five of them scoring the maximum CVSS base score of 10.0. The affected releases are Crosswork 7.2.1 and earlier, fixed in 7.2.1-SP.
The flaws were found during Cisco's own internal testing, and none is known to be exploited. These two facts pull in opposite directions.
What was fixed
Among the maximum-severity entries, CVE-2026-20030 is an SQL injection, CVE-2026-20357 is a missing authentication check on a critical function, and CVE-2026-20358 concerns external control of the file system. CVE-2026-20359 scores 9.9.
A 10.0 score is not just about consequence. It means the flaw is reachable over a network, requires no privileges and no user interaction, and leads to a complete compromise of confidentiality, integrity, and availability. Finding five of those in one product release is unusual.
Crosswork is the control plane, not a workload
The severity scores are high, but the real story is where these flaws were found.
Crosswork is Cisco's network automation and orchestration suite. It does not run alongside the network; it configures it. An operator uses it to push changes across routers and switches, manage service provisioning and hold the intended state of the infrastructure.
An unauthenticated flaw in an ordinary application compromises that application. A flaw like this in the orchestrator compromises the entire network it manages. The attacker gains not just a system, but the authority to reconfigure all systems, pushing malicious changes through the same channels as legitimate ones.
Missing authentication on a critical function is the most pointed of the three. It means a function that should have verified who was calling did not. In an orchestration platform, the functions worth protecting are the ones that change configuration.
Nine at once, found internally, is a specific kind of signal
Cisco titled this a security hardening release, and that framing is more informative than a routine advisory would be.
Finding nine vulnerabilities at once, all internally, suggests a dedicated security review, not a trickle of independent bug reports. Someone was tasked with taking a hard look at this product, and this is what they found.
This suggests two things at once. On one hand, the process worked: Cisco found and fixed these flaws before attackers did. On the other, five maximum-severity flaws were sitting in a shipping network orchestrator until a dedicated review found them. The advisory does not say what prompted that review.
The distinction from Cisco's recent record matters. Several 2026 disclosures — the Catalyst SD-WAN privilege escalation exploited for months before disclosure, the Unified CM server-side request forgery, the ASA denial of service that reached the Known Exploited Vulnerabilities catalogue with a three-day federal deadline — were found because they were being used. This set was found before that. Earlier is materially better.
Not known to be exploited is a statement about visibility
The phrase "not known to be exploited" is precise, but it is narrower than it sounds and should not be read as simple reassurance.
It means no exploitation has been observed. For a flaw found internally and never published, that is close to expected: an attacker would have needed to discover the same issue independently. But Crosswork sits inside service provider and large enterprise networks, and organisations of that kind do not routinely publish intrusion findings. Absence of observation is weaker evidence than absence of exploitation.
The window also changes today. Publishing an advisory with a version number and a vulnerability class gives every party the starting point for building an exploit, and the interval between disclosure and working proof of concept for a critical enterprise flaw has repeatedly been days. The GitLab code injection this month came under active exploitation within days of public disclosure.
The useful way to read "not known to be exploited" is that defenders have a head start. It is measured in days, and it should not be wasted.
Why the patch is harder than the number suggests
Applying patch 7.2.1-SP is simple on paper but difficult in practice.
An orchestration platform is exactly the system operators are most reluctant to restart, because it is the system that fixes everything else. Patching it means a maintenance window on the tool used to manage maintenance windows, and in service provider environments those windows are scheduled weeks out and contractually constrained.
This reluctance is why management-plane vulnerabilities persist long after a fix is available. While waiting for a maintenance window, the only realistic mitigation is to check network reachability. Crosswork interfaces should not be exposed to general network segments, but in most deployments, nobody has checked that assumption recently.
What this means for operators in the region
Crosswork is deployed by telecommunications operators and large enterprises rather than by small businesses, which narrows exposure across ASEAN considerably but concentrates it where it matters.
Regional carriers running Cisco automation should treat this as a management-plane exposure review rather than a single patch task. The specific questions are which segments can reach the orchestration interfaces, whether that reachability was ever formally scoped, and whether administrative access to Crosswork requires multi-factor authentication in practice as opposed to on paper.
Singapore's critical information infrastructure operators have an additional reason to document the answer. The updated Code of Practice announced last month extends oversight to interconnected systems linked to designated infrastructure rather than the designated systems alone, and an orchestration platform that configures a regulated network is exactly the class of interconnected system that language was written to capture.
What remains unconfirmed
The full list of nine and the split between Crosswork and Secure Workload is not itemised in the available reporting, and the complete CVSS vector strings are not published alongside the scores. What prompted the internal hardening review is not described.
It is not established whether any of the flaws share a root cause, whether earlier Crosswork releases outside the stated range are affected, whether any workaround exists for organisations that cannot patch promptly, or whether the vulnerabilities are reachable in default configurations as against specific deployment modes.
What to watch for
First, watch the Known Exploited Vulnerabilities catalogue. If any of these five flaws appear there, a scheduled patch becomes an emergency.
The second is proof-of-concept publication. Public exploit code for a maximum-severity orchestration flaw compresses the timeline for everyone and is usually visible before exploitation is.
The third is whether Cisco says what triggered the review. A vendor that explains why it went looking makes it possible to judge whether comparable products deserve the same attention.
View author profile → · Editorial policy
