Cisco Catalyst SD-WAN Manager CVE-2026-20245

Mandiant's Google Threat Intelligence Group published a forensic reconstruction of an intrusion in which Cisco Catalyst SD-WAN Manager (formerly vManage) was compromised through CVE-2026-20245 as a zero-day — exploited at a communications service provider from late 2025 through March 2026, months before Cisco's advisory (Mandiant/GTIG, 2026-06-24). Mandiant attributes the activity to no named actor. The reason this matters beyond one victim: SD-WAN Manager is the control plane for an entire WAN fabric — root on the controller is push-access to every managed edge device — so it warrants the same monitoring tier as a VPN concentrator or firewall, and it is now one of several Cisco SD-WAN flaws confirmed exploited during 2026.

The vulnerability. CVE-2026-20245 (CVSS 7.8, no workaround) is a command-injection weakness in the SD-WAN Manager CLI tenant-upload handler: the feature that ingests a tenant-list CSV fails to sanitise file content before it reaches a shell context, so an authenticated operator can embed OS commands inside a crafted CSV and have them execute as root on the underlying Linux host (Cisco PSIRT, cisco-sa-sdwan-privesc-4uxFrdzx). The injected commands appended a new UID-0 account (troot) to the host's local account databases, giving the actor a persistent root login independent of the vManage application's own user model.

Kill chain (as Mandiant documents it):

• Initial access — the actor reached an authenticated position by abusing peering-authentication-bypass flaws CVE-2026-20127 / CVE-2026-20182 to enrol unauthorised peering and obtain SSH as the vmanage-admin account, or alternatively by using certificate material stolen in a previous compromise (T1190, T1078.004).
• Privilege escalation — exploitation of CVE-2026-20245 via the crafted tenant CSV, executing as root (T1068).
• Persistence — creation of the troot UID-0 account in the host account databases, reachable via su (T1136.001).
• Defense evasion / anti-forensics — the actor changed the legitimate admin password and then reverted it to its original value to reduce detection probability, and deleted command history, syslog entries, and the uploaded files after use (T1070.003).

Hunt and detection concepts. The decisive gap is that vManage's own health dashboards do not surface OS-level account creation — detection has to happen on the underlying host. Baseline and monitor /etc/passwd and /etc/shadow for accounts added since a known-good snapshot (a UID-0 account other than root is the high-fidelity signal here). Review SD-WAN Manager audit logs for tenant-upload CLI/API invocations and correlate them with subsequent privileged shell activity; alert on child processes spawned by the tenant-upload service, and on shell-history truncation or gaps on the controller host. Because the actor reverted the admin password, an unexplained password-change-then-revert pair in admin account auditing is itself worth investigating.

Hardening. Upgrade to a fixed train — 20.9.9.2, 20.12.7.2, 20.15.4.5, 20.15.5.3, 20.18.3.1, or 26.1.1.2 — as there is no workaround. Restrict which operators hold privileged CLI roles, place the management/northbound interfaces behind a source-IP ACL rather than exposing them broadly, enforce MFA on all administrator accounts, and rotate SD-WAN admin credentials (including the default vmanage-admin) on any controller that may have been exposed before patching. Cisco's Catalyst SD-WAN Hardening Guide carries the vendor's own configuration baseline.