Cisco SD-WAN Is Under Active Attack: 3 Exploited Catalyst Manager CVEs and the Patch Plan

#security #networking #cisco #devops

If you run Cisco Catalyst SD-WAN Manager, this is a patch-now situation.

Cisco has now confirmed that three SD-WAN vulnerabilities are being actively exploited in the wild, and the important detail is that attackers are chaining bugs together, not just using the headline CVSS 10.0 issue. That means a "medium" or "high" score on its own is not a comfort signal here.

In this post, I’ll break down the attack chain, the affected releases, the fixed versions, and the hardening steps worth doing before your next maintenance window.

TL;DR

3 Cisco SD-WAN CVEs are now confirmed exploited in the wild

Attackers are chaining auth bypass, credential exposure, and file overwrite bugs

There are no workarounds that fully fix this, patching is the answer

If your SD-WAN control plane was internet exposed, assume higher risk and investigate for compromise

What happened

The timeline moved fast:

February 25, 2026: Cisco shipped patches for five Catalyst SD-WAN Manager vulnerabilities and disclosed that CVE-2026-20127 was already being exploited as a zero day.
February 25, 2026: CISA issued Emergency Directive ED 26-03 telling federal agencies to patch immediately.
March 5, 2026: Cisco updated the advisory and confirmed that CVE-2026-20128 and CVE-2026-20122 were also being exploited in the wild.

So this stopped being a single-bug story very quickly. It is a campaign against SD-WAN management infrastructure.

The five SD-WAN vulnerabilities at a glance

CVE	Severity	CVSS	Description	Exploited?
CVE-2026-20129	Critical	9.8	API authentication bypass leading to netadmin access	Not yet confirmed
CVE-2026-20126	High	7.8	REST API privilege escalation to root	Not yet confirmed
CVE-2026-20133	High	7.5	Information disclosure via filesystem access	Not yet confirmed
CVE-2026-20122	High	7.1	Arbitrary file overwrite via API leading to vManage privileges	Yes
CVE-2026-20128	Medium	5.5	DCA credential exposure that enables lateral movement	Yes

One of the useful reminders here is that attackers do not care about CVSS in isolation. They care about whether one flaw unlocks the next one.

A medium-severity credential leak becomes a serious incident if it gives an attacker a clean path to move across the SD-WAN control plane.

How the attack chains work

Based on Cisco Talos reporting and Cisco’s advisory updates, there are two important chains to understand.

Chain 1: the original zero-day path

1. Find an internet-exposed SD-WAN Manager or Controller
2. Exploit CVE-2026-20127 (authentication bypass)
3. Chain with an older privilege-escalation bug
4. Escalate to root
5. Modify scripts or services for persistence
6. Maintain access to the control plane

Chain 2: the newer March 2026 path

1. Exploit CVE-2026-20128 (DCA credential exposure)
2. Reuse those credentials against other SD-WAN nodes
3. Exploit CVE-2026-20122 (arbitrary file overwrite)
4. Gain vManage-level access
5. Potentially chain again for higher privileges

That is why patching only the loudest bug is not enough. The real risk is the kill chain.

Who is behind it

Cisco Talos tracks the actor exploiting the original zero-day as UAT-8616.

What matters operationally:

They appear to have targeted SD-WAN infrastructure for an extended period
They focus on control-plane compromise, not just one-off access
They have used persistence techniques, including modifying system scripts
Reporting indicates they may also downgrade software to reintroduce known-vulnerable states

That last point is especially nasty because it means version drift and software integrity suddenly matter a lot more than teams often assume.

What to do right now

1. Check your version

On vManage:

vmanage# show version

If you are not on a fixed release, you have work to do.

2. Upgrade to a fixed release

Current train	Fixed release
20.9.x	20.9.8.2
20.12.5 / 20.12.6	20.12.5.3 or 20.12.6.1
20.13 / 20.14 / 20.15	20.15.4.2
20.16 / 20.18	20.18.2.1

If you are on something older than 20.9, plan a supported upgrade path first.

3. Harden while you patch

These are the practical steps I would treat as baseline:

Block direct internet access to SD-WAN Manager and Controller whenever possible
If exposure is unavoidable, restrict access to known source IPs only
Disable HTTP on the web UI and use HTTPS only
Put management components behind a firewall with tight filtering
Ship logs to an external SIEM because local logs may not be trustworthy after compromise
Rotate admin credentials and verify role-based access assignments
Monitor for unauthorized software downgrades

4. Check for compromise, not just exposure

If your control plane was internet exposed at any point, I would assume elevated risk and validate:

Unusual API authentication events
Unexpected local or admin accounts
Script or service modifications on vManage/vSmart nodes
Unplanned configuration changes in the fabric
DCA-related access patterns that do not match normal operations

Why SD-WAN control planes are such attractive targets

Compromising a branch router is bad.

Compromising the management and policy layer of an SD-WAN fabric is much worse.

An attacker with control-plane access can potentially influence:

routing policy
traffic engineering
segmentation behavior
controller trust relationships
security policy distribution

That is why these vulnerabilities matter beyond patch management. They are a reminder that the SD-WAN controller stack should be protected like a crown-jewel system, not managed like a regular internal app.

Engineering lessons worth carrying forward

A few things this incident reinforces:

Management planes need zero-trust thinking too.
If your controller is reachable from too many places, you are giving attackers a simpler first hop.
CVSS is not enough for prioritization.
A medium bug that exposes credentials can outrank a higher-severity bug if it fits a live chain.
External logging is mandatory for critical control planes.
If local telemetry can be tampered with, your incident response starts blind.
Version integrity matters.
Track unexpected downgrades, not just upgrades.
Patching windows for management infrastructure should be shorter.
The blast radius is too large to treat SD-WAN control components like low-priority admin systems.