Cisco has disclosed a critical vulnerability in Cisco Catalyst SD-WAN Manager (formerly vManage) that is already being exploited in the wild. The flaw allows an unauthenticated, remote attacker to gain administrative privileges over the management plane of an organization's entire SD-WAN fabric. Let that sink in: no credentials required, remote code execution-level impact, and the target is the single pane of glass that controls your WAN edge routers, policies, and templates.
I've responded to multiple engagements where the management plane was the initial blast radius multiplier — once an adversary owns SD-WAN Manager, they own the routing policy for every site, can push malicious templates to thousands of edges, and can stage persistence that survives individual device rebuilds. This is not a vulnerability to queue for next month's patch cycle. If you run Catalyst SD-WAN Manager and it is reachable beyond a tightly restricted management network, treat this as an active incident until proven otherwise.
Technical Analysis
Affected Products and Platforms
The vulnerability affects Cisco Catalyst SD-WAN Manager (the management and orchestration platform previously known as vManage) when exposed to untrusted networks. Organizations running the controller on-premises or self-hosted in cloud environments are the primary concern — Cisco-hosted cloud instances are typically patched by Cisco on an accelerated schedule, but you must verify this with your account team rather than assume it.
The attack surface here is the web-based management interface and its underlying API endpoints. In real deployments, we routinely find vManage/SD-WAN Manager instances listening on TCP 443 (and legacy management ports) reachable from far broader network segments than administrators realize — sometimes directly internet-exposed. Shodan reconnaissance for SD-WAN Manager fingerprints is trivial, and threat actors actively enumerate these panels.
How the Attack Works (Defender's View)
Based on Cisco's advisory and the exploitation reporting, the flaw sits in the authentication layer of the management interface. An attacker can send crafted requests to the SD-WAN Manager application and bypass normal authentication controls, landing in an authenticated session with administrative privileges — no valid credentials, no prior access, no user interaction.
From there, the post-exploitation chain is well understood from prior SD-WAN compromises:
- Reconnaissance of the fabric: The attacker enumerates all managed WAN edge devices, sites, templates, and policies through legitimate API calls.
- Credential and configuration harvesting: Device configurations, attached policies, and any stored credentials or pre-shared keys become accessible.
- Malicious policy/template push: The attacker modifies or attaches templates to edge routers, enabling persistence, traffic redirection, or ACL changes that open attacker infrastructure.
- Account creation for persistence: A common tradecraft pattern after admin-level access is creating a new local administrative user (or an API token) so access survives patching of the original flaw.
Exploitation Status
This is confirmed active exploitation, not theoretical. The vulnerability is being used against real targets, which historically means public PoC and broader criminal adoption follow within days to weeks. Management-plane vulnerabilities in network infrastructure are a favorite of both state-sponsored actors (for long-dwell espionage via telecom and enterprise WANs) and sophisticated criminal groups (for staging ransomware and data theft). Assume exploitation attempts against any reachable instance have already occurred.
Detection & Response
Because SD-WAN Manager is a Linux-based appliance, your detection strategy hinges on three telemetry sources: the controller's own authentication and audit logs (forwarded via syslog), network flow/firewall data around the management interface, and process/file telemetry if you can deploy forensic tooling on the appliance or its host. Below are field-ready detections. Tune thresholds to your environment, but do not tune them into silence.
Sigma Rules
---
title: Cisco SD-WAN Manager Suspicious Authentication from External Source
id: 4e8b2c1a-9f3d-4a7e-b5c2-8d1f6a3e9c07
status: experimental
description: Detects successful or repeated authentication events against Cisco Catalyst SD-WAN Manager (vManage) originating from IP addresses outside the designated management network, consistent with exploitation of the unauthenticated access vulnerability.
references:
- https://sec.cloudapps.cisco.com/security/center/publicationListing.x
- https://attack.mitre.org/techniques/T1190/
author: Security Arsenal
date: 2026/04/06
tags:
- attack.initial_access
- attack.t1190
logsource:
product: cisco
service: vmanage
detection:
selection:
- EventType|contains: 'login'
- Message|contains:
- 'logged in'
- 'authentication successful'
- 'Login successful'
filter_mgmt_net:
SourceIP|cidr:
- '10.0.0.0/8'
- '192.168.0.0/16'
- '172.16.0.0/12'
condition: selection and not filter_mgmt_net
falsepositives:
- Administrators legitimately connecting over VPN with non-RFC1918 egress addresses — whitelist your VPN egress ranges
level: high
---
title: Cisco SD-WAN Manager New Local Admin Account Creation
id: 7c2d5e8f-1b4a-4c9d-a6e3-2f8b7d5c1a94
status: experimental
description: Detects creation of new user accounts or privilege changes on Cisco Catalyst SD-WAN Manager, a common persistence technique following admin-level compromise of the management plane.
references:
- https://attack.mitre.org/techniques/T1136/
author: Security Arsenal
date: 2026/04/06
tags:
- attack.persistence
- attack.t1136
- attack.t1136.001
logsource:
product: cisco
service: vmanage
detection:
selection:
Message|contains:
- 'User created'
- 'user added'
- 'created user'
- 'netconf user'
- 'role updated'
- 'privileges changed'
falsepositives:
- Legitimate provisioning by network administrators — alert should trigger change-ticket correlation, not be suppressed
level: medium
---
title: Suspicious Process Execution on Linux Network Management Appliance
id: 9a4f7b2e-5c8d-4e1f-b3a6-6d9c2e8f4b15
status: experimental
description: Detects the web/application server on a Linux-based network management appliance (such as Cisco SD-WAN Manager) spawning shells or command interpreters, indicating post-exploitation activity.
references:
- https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/04/06
tags:
- attack.execution
- attack.t1059.004
logsource:
category: process_creation
product: linux
detection:
selection_parent:
ParentImage|endswith:
- '/java'
- '/nginx'
- '/apache2'
- '/httpd'
- '/tomcat'
selection_child:
Image|endswith:
- '/sh'
- '/bash'
- '/dash'
- '/python'
- '/python3'
- '/perl'
- '/curl'
- '/wget'
- '/nc'
- '/ncat'
condition: selection_parent and selection_child
falsepositives:
- Vendor software upgrades and legitimate scheduled maintenance scripts — correlate with Cisco TAC sessions and maintenance windows
level: high
KQL Hunt (Microsoft Sentinel / Defender)
Most enterprises ingest Cisco controller syslog into Sentinel via the CEF/Syslog connector. The following query hunts for successful logins to SD-WAN Manager from outside expected source ranges, spikes in authentication failures (exploitation attempts), and new account creation events — the three highest-signal behaviors for this threat.
let MgmtSources = dynamic(["10.10.5.", "10.10.6.", "192.168.100."]); // REPLACE with your jump-host / mgmt subnets
let Lookback = 14d;
let AuthEvents = Syslog
| where TimeGenerated > ago(Lookback)
| where Computer has_any ("vmanage", "sdwan") or ProcessName has_any ("vmanage", "sdwan")
| where SyslogMessage has_any ("login", "logged in", "authentication", "user created", "User created")
| extend SrcIP = extract(@"(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})", 1, SyslogMessage)
| extend IsExpectedSource = SrcIP startswith_any (MgmtSources);
AuthEvents
| extend Verdict = case(
SyslogMessage has ("user created") or SyslogMessage has ("User created"), "ACCOUNT-CREATION",
SyslogMessage has_any ("logged in", "Login successful") and not(IsExpectedSource), "SUCCESS-EXTERNAL-SOURCE",
SyslogMessage has_any ("failed", "invalid"), "FAILED-AUTH",
"OTHER")
| summarize EventCount = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated), Sources = make_set(SrcIP) by Verdict, Computer, bin(TimeGenerated, 1h)
| where Verdict != "OTHER"
| order by LastSeen desc;
// Secondary: network connections to the management interface from untrusted space (CEF/firewall logs)
CommonSecurityLog
| where TimeGenerated > ago(Lookback)
| where DestinationPort in (443, 8443, 22) and DestinationHostName has_any ("vmanage", "sdwan") // adjust to your controller FQDNs
| where not(SourceIP startswith "10.") and not(SourceIP startswith "192.168.")
| summarize ConnectionCount = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated) by SourceIP, DestinationIP, DestinationPort, DeviceAction
| order by ConnectionCount desc;
Velociraptor VQL
If you can deploy Velociraptor (or run an offline collection) against the appliance host or a co-located Linux jump host used to administer it, hunt for shells spawned by application processes, unexpected outbound connections from the controller, and recently modified web application files.
-- Hunt for shells spawned by web/app server processes and suspicious outbound connections
SELECT Pid, Ppid, Name, Exe, CommandLine, Username, CreateTime
FROM pslist()
WHERE (Name =~ '^(sh|bash|dash|python|python3|perl|nc|ncat|socat)$'
AND CommandLine =~ '(curl|wget|base64|/dev/tcp|chmod \+x|/tmp/)')
OR Exe =~ '/(tmp|var/tmp|dev/shm)/'
-- Enumerate active network connections to spot C2 or unexpected egress from the controller
SELECT Pid, Name, Status, Laddr, Lport, Raddr, Rport
FROM netstat()
WHERE Status =~ 'ESTABLISHED'
AND NOT (Raddr =~ '^(10\.|192\.168\.|172\.(1[6-9]|2[0-9]|3[01])\.)' OR Raddr = '' OR Rport = 0)
ORDER BY Raddr
Remediation
Act in this order. Speed beats elegance here.
- Patch immediately. Apply the fixed software release identified in Cisco's official security advisory for this vulnerability. Retrieve the exact fixed version for your train from the Cisco Security Advisory page (https://sec.cloudapps.cisco.com/security/center/publicationListing.x) and the Cisco Software Checker. Do not guess version numbers — the advisory is the authoritative source, and Cisco frequently issues follow-up corrections when initial fixes are incomplete.
- Restrict management-plane exposure now, patched or not. SD-WAN Manager should never be reachable from the internet or from general user VLANs. Enforce ACLs/security groups permitting TCP 443 (and any required controller peering ports) only from designated management subnets and jump hosts. If your instance is internet-facing, block it at the edge today — patching takes hours; ACLs take minutes.
- Hunt before you patch, if forensically feasible. Capture controller logs (vmanage-server logs, audit logs, and syslog archives), running process lists, and user/account inventories before upgrading, since upgrades can destroy volatile evidence. Check for: unfamiliar local user accounts, API tokens you didn't issue, logins from IPs outside your management network, and template/policy changes outside change windows.
- Assume compromise of the management plane means compromise of the fabric. If you find evidence of unauthorized access: rotate all credentials the controller stores or uses (device credentials, TOTP/admin passwords, API keys, certificates where feasible), audit every device template and policy attached in the last 90 days, and review edge router configurations for unauthorized ACL entries, static routes, or new local users.
- Reset all SD-WAN Manager administrative passwords and revoke sessions/tokens after patching, regardless of findings. Exploited auth-bypass flaws frequently leave behind secondary access paths.
- Monitor CISA KEV and your ISAC feeds. Vulnerabilities in Cisco management infrastructure under active exploitation are routinely added to CISA's Known Exploited Vulnerabilities catalog with binding remediation deadlines for federal agencies — treat those deadlines as your own benchmark even if you're not bound by BOD 22-01.
- Long-term hardening: enforce MFA/SSO for controller access, forward all controller audit logs to a SIEM the controller cannot reach, alert on any configuration change outside approved change windows, and include management-plane compromise in your IR tabletop scenarios. The organizations that fare worst in these events are the ones whose controllers were silent black boxes.
If you lack the internal capacity to hunt your SD-WAN fabric for compromise or validate your exposure, this is precisely the class of incident where outside DFIR support pays for itself — the difference between "patched a bug" and "evicted an actor with six months of dwell time" is usually one thorough hunt.
Related Resources
Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.