Cisco's SD-WAN Has Logged Seven Actively Exploited Zero-Days This Year

Cisco shipped a patch on June 10 for a flaw in Catalyst SD-WAN Manager that lets an attacker run commands as root. By the time the fix landed, the bug already had a name in the place that matters: CISA's Known Exploited Vulnerabilities catalog, the federal government's list of flaws confirmed to be under attack in the real world. The remediation deadline for federal agencies passed on June 23. If you run this software, that deadline was yours too, whether or not anyone told you.

The flaw is CVE-2026-20245. On its own it is a competent but unremarkable bug. What makes it worth your attention is the counter next to it: it is the seventh Cisco SD-WAN vulnerability confirmed as actively exploited in 2026, in a single product line, in not quite six months. That number is the story. One zero-day is a coding mistake. Seven in half a year, clustered in the same few components, is a structural problem.

What the bug actually does

SD-WAN Manager is the controller. It is the box that defines routing policy, traffic steering, and security configuration for every branch office in a software-defined wide-area network. Compromise it and you do not own one server. You own the steering wheel for the whole network. Cisco used to call it vManage, which is the name you will still see in older docs.

Here is how Cisco describes the flaw: the CLI "could allow an authenticated, local attacker to execute arbitrary commands as root by supplying a crafted file to the affected system." Translated once: the command-line interface accepts file uploads, does not properly check what is in them, and an attacker who uploads the right malformed file can smuggle in shell commands that run with full root privileges. Classic input validation failure. The CVSS score is 7.8 out of 10, which sounds moderate until you remember what the box controls.

The catch, and the reason this is rated "authenticated" rather than "anyone on the internet," is that you need netadmin-level credentials to do the upload. That sounds like a meaningful barrier. It is not, and Cisco says so plainly. Those credentials can be obtained by chaining two earlier holes in the same product: CVE-2026-20182, an authentication bypass rated a maximum 10.0 that Rapid7 disclosed in May and Cisco patched on May 14, and CVE-2026-20127, an older credential-access path that a threat group Cisco tracks as UAT-8616 has reportedly been exploiting since 2023. So the real attack is: bypass authentication with one bug, harvest netadmin rights, then use this bug to get root. The "you need credentials first" caveat assumes the credentials are hard to get. In this codebase, they have not been.

Google's Mandiant researchers Chester Sng, Pete Boonyakarn, and Logeswaran Nadarajan found CVE-2026-20245 while it was already being exploited. Cisco disclosed it on June 5. At disclosure there was no patch, only the advice to make sure you had applied the earlier fixes. Patches started shipping on June 10, across the various SD-WAN Manager release trains (20.9.9.2, 20.12.7.2, 20.15.4.5, 20.15.5.3, 20.18.3.1, and 26.1.1.2, among others). Cisco also said it observed a "limited" number of cases where attackers used the flaw to push configuration changes down to edge devices. On a controller, "limited configuration changes" is not a small thing. That is an attacker reaching past the controller and reaching into the branch sites it manages.

Seven is a pattern, not a streak

CVE-2026-20245 joins CVE-2026-20182, CVE-2026-20127, CVE-2026-20122, CVE-2026-20128, CVE-2026-20133, and CVE-2022-20775 on the list of Cisco SD-WAN flaws flagged as actively exploited this year. Seven confirmed zero-days in one product family before July is not what a healthy codebase looks like.

It is worth being precise about what that does and does not mean. It does not mean Cisco's SD-WAN is uniquely terrible engineering, and it does not mean every other vendor's gear is clean. Network infrastructure across the industry has become a priority target, because it sits below the endpoint security and the firewalls and the application controls, and because it tends to be patched on slow, change-managed schedules. Attackers go where the patching is slow and the payoff is high. SD-WAN controllers are close to an ideal target on both axes.

What the pattern does suggest is accumulated debt in specific places. The vulnerabilities keep landing in the same handful of components: the management-plane authentication, the CLI input handling, the inter-device trust machinery. When the same subsystems keep producing the same class of bug, that points to a design that was not built to assume the management plane is hostile. It is being retrofitted to that assumption one CVE at a time, in production, while it is under attack.

The Arista flaw nobody is going to patch

The same June 23 CISA deadline covered a second exploited flaw, and it is the more interesting of the two from an engineering standpoint. CVE-2026-7473 affects Arista's EOS network operating system on switches configured for tunnel decapsulation. Where the Cisco bug needs credentials, this one needs nothing but a network path to the device.

The mechanism is a logic error in the forwarding pipeline. A switch set up to terminate tunnels checks whether an incoming packet's outer destination address matches a configured decapsulation address. If it matches, the switch unwraps the packet and forwards the inside. The bug: the switch never verifies that the tunnel protocol type matches what it was configured to handle. So a switch set up only for VXLAN will happily unwrap a GRE or IP-in-IP packet aimed at the same address, and drop the inner payload straight into the internal network. That defeats the VLAN and VRF segmentation the network's security design depends on. No login, no alert, no obvious anomaly unless you are specifically watching tunnel-protocol counters against your decap addresses.

Arista's answer, per its Security Advisory 0137 and reporting from SecurityWeek, is that no software patch is coming. The company's stated reasoning is that a code-level fix could break existing deployed configurations. Instead it is directing customers to access-control-list mitigations that permit only the expected tunnel protocol to reach the decapsulation address and block the rest. On older platforms those ACL changes require TCAM profile updates, which are themselves traffic-affecting operations you have to schedule into a maintenance window. The affected hardware spans the 7020R, 7280R/R2, and 7500R/R2 series, with certain IPv6 decap configurations extending exposure to the 7280R3, 7500R3, and 7800R3 lines. The flaw was reported by a Comcast team and exploitation was already underway when Arista published the advisory on May 5, more than a month before it reached the CISA catalog on June 9.

"No patch planned" is a defensible engineering call when a fix would break working networks. It is also a quiet admission that the permanent remediation for an actively exploited flaw is now a configuration project the customer has to run, test, and maintain themselves. There is a second sting: because the exposure depends on configuration rather than software version, ordinary vulnerability scanners that match version strings will often report affected switches as clean. The signal that you are vulnerable does not show up where most teams look for it.

What to actually do

If you run Catalyst SD-WAN Manager, apply the patches Cisco started releasing on June 10, and before you upgrade, collect forensic artifacts with the request admin-tech command. Cisco warns explicitly that patching after a compromise does not evict an intruder or undo configuration changes already pushed to edge devices. Confirm that CVE-2026-20182 and CVE-2026-20127 are fully remediated, because those are the documented paths to the credentials this bug needs. Check the scripts.log file for the upload entries Cisco lists as indicators of compromise, and treat any internet-exposed controller as high-risk regardless of patch status.

If you run affected Arista EOS switches, first check whether they are actually doing tunnel decapsulation. If there is no VXLAN VTEP, GRE tunnel interface, or decap-group configured, this particular bug does not apply to you. If there is, find out whether untrusted networks can reach the decapsulation address, and apply the ACL mitigations in Advisory 0137. Since no patch is coming, those ACLs are the fix, not a stopgap.

For everyone else, the takeaway is duller and more durable than any single CVE. The CISA catalog only lists flaws confirmed to be exploited in the wild, and network infrastructure keeps showing up on it. The management plane and the forwarding fabric are where capable attackers are spending their time, because owning the controller or defeating the segmentation scales better than popping one more laptop. That is worth more of your patching budget than it probably gets.