CRITICAL: Cisco Patches Three CVSS 9.9 Catalyst SD-WAN Flaws and Seven IOS XE Bugs

Cisco spent August 5 pushing out what it calls security hardening releases, which is polite vendor language for a substantial pile of things that should never have shipped in the first place. Twelve vulnerabilities landed across Catalyst SD-WAN and IOS XE Software. Three of them carry a CVSS score of 9.9. One more sits at 9.8. Cisco says none are being exploited in the wild, which is genuinely good news, but the word doing all the heavy lifting in that sentence is "yet."

If you run Catalyst SD-WAN anywhere in your estate, this is a drop everything and patch situation. Not because someone is currently rummaging through your controllers, but because SD-WAN Manager is the single most valuable box in a modern branch network, and Cisco has just published a roadmap to three separate ways of owning it. Every researcher and every ransomware affiliate with a diffing tool read the same advisory you did.

The SD-WAN side

The three critical entries are CVE-2026-20303, CVE-2026-20304, and CVE-2026-20310, all tracked in advisory cisco-sa-hardening-sdwan-faLcR3K. Each rates 9.9 on CVSS v3.1, and the vector string explains that number better than any adjective could. It reads AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H, which unpacks to network reachable, low attack complexity, low privileges required, no user interaction, and a scope change that ends in total loss of confidentiality, integrity, and availability. That scope change is the part worth staring at. It means the attacker does not stay in the application context where they started. They break out of it and land on the underlying operating system.

CVE-2026-20303 is filed under CWE-20, improper input validation, and Cisco's own description folds path traversal and external control of file paths into the same entry. CVE-2026-20304 is CWE-284, improper access control, which the advisory describes as covering authorization, authentication, privileges, and bypasses generally. CVE-2026-20310 is CWE-59, improper link resolution before file access, the classic symlink problem where a privileged process follows a link it should have refused and then reads or writes somewhere it has no business touching. Put those three in one product and you have file read, file write, and an authorization bypass sitting next to each other. Chaining them is not a research project. It is an afternoon.

Two more round out the same advisory. CVE-2026-20312 scores 8.8 under CWE-312, cleartext storage of sensitive information, which in a management plane almost always means credentials, tokens, or keys sitting on disk in a form that anyone with file read access can simply pick up and use. Notice how neatly that pairs with a path traversal bug in the same product. CVE-2026-20313 scores 7.7 under CWE-1284, improper validation of specified quantity in input, the sort of flaw that generally translates to a resource exhaustion or denial of service condition rather than code execution.

The IOS XE side

The router and switch half of the release is advisory cisco-sa-hardening-iosxe-V8NMuMZJ, and it covers seven vulnerabilities. The worst is CVE-2026-20272 at CVSS 9.8, categorized as CWE-74, improper neutralization of special elements, which is the formal way of saying command injection. Behind it sits CVE-2026-20267 at 9.0, another improper access control issue under CWE-284.

The remaining five all land at 8.6 and represent a fairly broad sweep of memory and logic defects. CVE-2026-20268 is CWE-119, improper restriction of operations within the bounds of a memory buffer. CVE-2026-20269 is CWE-664, improper control of a resource through its lifetime. CVE-2026-20270 is CWE-682, incorrect calculation. CVE-2026-20271 is CWE-691, insufficient control flow management. CVE-2026-20273 is CWE-20, improper input validation with a path traversal flavor. An 8.6 is not a 9.9, but on a device that terminates your WAN circuits and enforces your access lists, none of these are things you leave sitting around for a quarter.

The part nobody is talking about enough

Buried in Cisco's language is a detail that deserves more attention than it is getting. The company states these vulnerabilities were found during internal security testing "using existing testing processes as well as frontier AI models."

That is Cisco telling you, in an advisory footnote, that large language models are now productively finding real critical vulnerabilities in mature, heavily audited, decades-old enterprise networking code. Twelve of them at once, three at 9.9. This is not a marketing claim about an AI security product. It is a vendor quietly explaining why its patch volume suddenly looks different.

Take the obvious next step in that reasoning. If Cisco can point frontier models at its own source and shake out three critical bugs, so can everyone else point those models at Cisco's binaries and patch diffs. The window between advisory publication and working exploit has been shrinking for years for boring economic reasons. This accelerates it further. Patch cadence assumptions built in 2019 are not going to survive 2026, and the thirty day patching SLA in your service agreement is starting to look like a liability rather than a commitment.

Who is affected and what actually fixes it

On the SD-WAN side, the advisory covers Catalyst SD-WAN Software across every deployment model Cisco sells, meaning on-premises, Cloud-Pro, Cisco managed cloud, and the Government FedRAMP environment. If you are running Cisco managed cloud instances, Cisco has already pushed those to 20.15.602 automatically, so that portion of your estate is handled without you lifting a finger. Everything else is on you.

For self-managed deployments the fix path runs by branch. The 20.9 branch goes to 20.9.10. Anything on 20.10, 20.11, or 20.12 moves to 20.12.8.1. The 20.13, 20.14, and 20.15 branches go to 20.15.6. The 20.16 and 20.18 branches go to 20.18.4. If you are on 26.1, take 26.1.2. Anything older than 20.9 has no fixed release at all and needs a migration onto a supported branch rather than a patch, and it is worth noting that 20.11, 20.13, 20.14, and 20.16 have reached end of life, so users sitting on those are upgrading across a branch boundary whether they planned to or not.

IOS XE follows the same pattern. Affected releases include 17.9, 17.12, 17.15, 17.18, and 26.1, with fixes available in 17.9.10, 17.12.8, 17.15.6, 17.18.4 or 17.18.4a, and 26.1.2 respectively.

The uncomfortable line in both advisories is identical and unambiguous. There are no workarounds. You cannot configure your way out of this, you cannot mitigate it with an access list, and there is no toggle to flip while you wait for a maintenance window. The only remediation Cisco offers is a fixed image.

What exploitation would actually look like

The PR:L in that vector string, meaning low privileges required, is where a lot of teams will convince themselves they are safe. They should not. Low privileges does not mean administrator. It means any authenticated account at all, including the read-only monitoring account you handed to the NOC three years ago, the service account the observability platform uses, the contractor login nobody ever disabled, or the credentials sitting in an infostealer log that somebody bought for the price of a sandwich.

That is the realistic attack chain here. Nobody is going to punch through a Catalyst SD-WAN Manager from the open internet with no credentials. What happens instead is that an attacker phishes a helpdesk account, pivots inward, finds vManage reachable on the management network because it always is, and turns a nothing-account into root on the box that holds your device inventory, your configuration templates, and your certificate material. From there they are not attacking your network anymore. They are administering it.

So while you are scheduling upgrades, spend twenty minutes pulling the full list of accounts that can authenticate to your SD-WAN Manager instances at all. Most organizations are unpleasantly surprised by that list. Every one of those accounts is now a critical-severity foothold rather than a low-privilege inconvenience.

Detection while you wait for the window

Assuming you cannot patch tonight, there is monitoring worth standing up in the meantime. Watch for unexpected file writes and symlink creation on SD-WAN Manager, since two of the three criticals are file access bugs and both would leave artifacts on disk. Alert on authentication to vManage from source addresses outside your normal management ranges, and on any successful authentication by service or read-only accounts that historically only ever poll an API. Track creation of new administrative users and any modification to configuration templates or device groups, because template modification is the quietest possible way to push a malicious change to every branch at once. On the IOS XE side, treat any unexpected process execution or unexplained reload as worth a look, and confirm your device configurations are backing up somewhere the devices themselves cannot reach.

Also verify the obvious thing. Management interfaces on this class of device should not be reachable from user VLANs, guest networks, or anything a phished laptop can touch. That control does not fix these CVEs, but it meaningfully raises the cost of reaching them.

The MSP angle

Twelve CVEs in a single day across two flagship Cisco platforms is the clearest possible argument for a managed patching and vulnerability management retainer, and the "no workarounds available" line writes the proposal for you, because it proves that compensating controls do not substitute for a maintenance program. Pair the upgrade work with a paid network device access review, since the low-privileges-required detail turns every forgotten monitoring and contractor account into a billable finding, and that review sells the identity hygiene and credential monitoring services that clients otherwise wave off as theoretical.