Vulnerability Analysis

CVE-2026-20245: Cisco SD-WAN Manager Zero-Day Enables Root Access — No Patch Available

Executive Summary

CVE-2026-20245 is an actively exploited command injection vulnerability in Cisco Catalyst SD-WAN Manager's command-line interface that allows an authenticated attacker with netadmin privileges to upload a crafted file and gain root-level command execution on the management plane. As of June 5, 2026, Cisco has confirmed active exploitation with no patch and no workaround available. This is the seventh Cisco SD-WAN zero-day disclosed in 2026 and is chainable with two prior CVSS 10.0 authentication bypasses — CVE-2026-20127 and CVE-2026-20182 — creating a complete unauthenticated-to-root kill chain against all deployment types including FedRAMP government environments.

1. What Is This Vulnerability?

CVE-2026-20245 is a command injection vulnerability residing in the CLI layer of Cisco Catalyst SD-WAN Manager (formerly vManage). The flaw stems from insufficient validation of user-supplied input when files are uploaded through the management CLI interface. An attacker who has obtained netadmin-level credentials can craft a malicious file, upload it through the CLI, and trigger arbitrary OS command execution that escalates to root on the underlying device.

Root access on the SD-WAN Manager is not a bounded compromise. The Manager is the control plane for the entire SD-WAN fabric it oversees — it distributes configuration and security policy to every edge router in the deployment. An attacker with root on the Manager can:

  • Push rogue configuration changes to all connected edge devices
  • Modify routing policies and redirect or intercept traffic flows
  • Extract VPN private keys
  • Disable or reconfigure network security policies across the enterprise
  • Establish persistent backdoors through NETCONF management channels

Cisco disclosed the vulnerability on June 5, 2026 — after exploitation was already underway — meaning the vulnerability reached public awareness as an active zero-day rather than a proactively patched flaw.

Attack Vector

The exploitation mechanism works as follows:

  1. The attacker uploads a specially crafted file to Cisco Catalyst SD-WAN Manager through the CLI interface
  2. The file name or content contains shell metacharacters or command sequences that the SD-WAN Manager fails to sanitize
  3. The unsanitized input is passed to an OS-level function
  4. The injected command executes with root privileges

Forensic investigation of real-world incidents identified the mechanism through /var/log/scripts.log entries revealing suspicious invocations of vconfd_script_upload_tenant_list.sh with attacker-controlled file paths referencing files in the /home/admin/ directory with unexpected filenames.

An alternative privilege escalation technique observed in UAT-8616 intrusions involves temporary software version downgrade to re-expose CVE-2022-20775, an older escalation vulnerability, before restoring the original software version. This version-manipulation tradecraft indicates sophisticated, long-dwell-time actors who plan exploitation paths methodically to avoid detection.

Real-World Impact

Cisco Talos attributed primary exploitation to UAT-8616, a sophisticated threat actor assessed with high confidence to be state-sponsored based on operational tradecraft consistent with espionage campaigns. UAT-8616 has been operating in Cisco Catalyst SD-WAN environments since at least 2023 — three years before public disclosure of the first CVEs in this series. In February 2026, the Five Eyes intelligence partnership (US, UK, Canada, Australia, New Zealand) issued a joint advisory identifying CVE-2026-20127 exploitation as a threat to critical national infrastructure globally.

Post-compromise behavior observed in UAT-8616 intrusions includes:

  • Creation and immediate deletion of malicious accounts to obscure their existence in logs
  • SSH key injection into administrator accounts for persistent, credential-independent access
  • Manipulation of SD-WAN configuration through NETCONF channels to alter edge routing and security policy
  • Systematic clearing of authentication logs, command history files, and system logs across multiple paths

2. Who Is Affected?

Every organization running Cisco Catalyst SD-WAN Manager is affected, with no exempted deployment model:

Deployment Type Affected
On-premises installations ✅ Yes
Cisco Cloud-Pro ✅ Yes
Cisco Managed Cloud ✅ Yes
FedRAMP (US federal agencies) ✅ Yes

All software version trains are vulnerable. No fixed version exists as of the June 5, 2026 disclosure. This means approximately every Cisco Catalyst SD-WAN deployment in the world remains exposed pending a patch.

Why the Authentication Prerequisite Is Not Protective

CVE-2026-20245 requires netadmin-level access — but this prerequisite is effectively neutralized by two earlier 2026 CVEs:

  • CVE-2026-20127 (CVSS 10.0): Unauthenticated authentication bypass targeting the vdaemon service over DTLS on UDP port 12346. Allows a remote, unauthenticated attacker to obtain high-privileged internal access to the SD-WAN Controller.
  • CVE-2026-20182 (CVSS 10.0): A distinct but related flaw in the same vdaemon peering authentication mechanism. When exploited, injects an attacker-controlled SSH public key into the vmanage-admin account's authorized_keys file, granting persistent NETCONF access without any credentials for subsequent sessions.

The complete kill chain from the internet to root is: No credentials → CVE-2026-20127 or CVE-2026-20182 → netadmin access → CVE-2026-20245 → root on SD-WAN Manager → full enterprise network compromise.

Additionally, following the March 2026 public release of proof-of-concept code for earlier SD-WAN CVEs, Cisco Talos identified at least ten additional threat clusters beyond UAT-8616 conducting opportunistic exploitation of this product family. Security teams should treat unpatched deployments as potentially compromised rather than merely at elevated risk.

3. How to Detect It (Testing)

Manual Testing Steps

Step 1: Verify your SD-WAN Manager version

# Log in to SD-WAN Manager and run:
show version
# Check software train against Cisco advisory — as of June 5 2026, 
# all versions remain vulnerable to CVE-2026-20245

Step 2: Audit /var/log/scripts.log for exploitation indicators

# On the SD-WAN Manager host:
grep -i "vconfd_script_upload_tenant_list.sh" /var/log/scripts.log
# Look for invocations with unexpected file paths — particularly 
# paths referencing files in /home/admin/ with unusual filenames

Step 3: Check for unauthorized SSH key injection (CVE-2026-20182 indicator)

# Inspect authorized_keys for the vmanage-admin account:
cat /home/vmanage-admin/.ssh/authorized_keys
# Any key not explicitly provisioned by your operations team 
# is a confirmed indicator of CVE-2026-20182 exploitation

Step 4: Check for unexpected public-key authentication events

# Review SD-WAN Controller authentication logs:
grep "Accepted publickey for vmanage-admin" /var/log/auth.log
# Flag all entries originating from IP addresses not in your 
# known administrator workstation allowlist

Step 5: Audit netadmin-level accounts

  • Log in to SD-WAN Manager web UI → Administration → Users
  • Enumerate all accounts with netadmin role
  • Flag any accounts you cannot attribute to a known, active administrator

Step 6: Review edge device configuration change history

  • In SD-WAN Manager → Configuration → Templates → Feature Templates
  • Review the "Last Modified" timestamps and initiating usernames
  • Flag any configuration pushes that occurred outside of authorized change windows

Automated Scanning

Using Cisco's request admin-tech diagnostic collection:

# Run on ALL SD-WAN control plane components before any software changes
request admin-tech
# This captures log data that may be overwritten during updates — 
# essential for forensic preservation

Network-level exposure check (Shodan / internal scanning):

# Check whether UDP 12346 (DTLS vdaemon port) is exposed to untrusted networks
nmap -sU -p 12346 <sdwan-controller-ip>
# This port must NOT be reachable from the internet or untrusted network segments

SIEM detection query (Splunk example) for suspicious CLI file uploads:

index=sdwan sourcetype=sdwan_logs 
"vconfd_script_upload_tenant_list.sh" 
| table _time, host, user, file_path, src_ip
| where NOT match(src_ip, "^<authorized_mgmt_cidr>")

Code Review Checklist

For organizations that have custom scripts or integrations with SD-WAN Manager APIs:

  • All input passed to SD-WAN Manager CLI is sanitized — no shell metacharacters (; & | $ > < \ ( ) { }`)
  • File upload workflows validate filename and content before submission
  • Automation credentials are scoped to minimum required privilege (not netadmin unless required)
  • API authentication tokens are rotated on a defined schedule and revoked on service account changes
  • NETCONF access is restricted to known controller IP addresses only

4. How to Fix It (Mitigation)

⚠️ No patch is currently available for CVE-2026-20245. Cisco confirmed no workaround fully closes the vulnerability. The following steps reduce attack surface and compensating controls while awaiting a vendor fix.

Step-by-Step Remediation (Compensating Controls)

1. Preserve forensic evidence first

# Run on ALL SD-WAN control plane components before ANY changes
request admin-tech
# Save the output to offline, write-protected storage before patching

2. Patch the authentication-layer prerequisites immediately

If you have not already patched CVE-2026-20182 (fixed May 14, 2026) and CVE-2026-20127, do so immediately. Patching these authentication bypasses eliminates the unauthenticated entry point into CVE-2026-20245's required netadmin access. This is the highest-priority remediation action currently available.

Reference Cisco's security advisories:

  • cisco-sa-sdwan-rpa2-v69WY2SW (CVE-2026-20182)
  • cisco-sa-sdwan-unauthbp-qwCX8D4v (CVE-2026-20127)

3. Isolate the SD-WAN Manager management interface

Move the Manager's management interface (VPN 512) to a dedicated out-of-band management VLAN that is not accessible from the general corporate network, public-facing segments, or untrusted zones. This is the single most impactful compensating control for CVE-2026-20245 — if the CLI is only reachable from a known jump host, the file-upload exploitation path narrows dramatically.

4. Harden netadmin account access

# In SD-WAN Manager: Administration → Users
# Actions for every netadmin account:
# 1. Verify it belongs to an active, named administrator
# 2. Revoke netadmin on accounts that don't actively require it
# 3. Rotate credentials for all remaining netadmin accounts
# 4. Enable MFA for all administrative accounts

5. Audit and clean authorized SSH keys

# Check for injected keys from CVE-2026-20182 exploitation:
cat /home/vmanage-admin/.ssh/authorized_keys
cat ~/.ssh/authorized_keys  # For each admin account

# Remove any key not explicitly provisioned by your operations team:
# Edit authorized_keys and delete unauthorized entries
# Document all legitimate keys in your configuration management system

6. Restrict NETCONF access

In SD-WAN Manager configuration, restrict NETCONF access from the management plane to edge devices to a named allowlist of known-good controller IP addresses. This limits the blast radius if the Manager is compromised — preventing arbitrary configuration pushes to all edge devices.

Configuration Hardening

Additional hardening settings to apply immediately:

# SD-WAN vManage System Settings:
# - Enable VPN 512 management interface isolation
# - Set CLI session timeout to 15 minutes (reduce exposure window)
# - Restrict management access: specify allowed IP range for admin access
# - Enable audit logging for all CLI sessions
# - Set failed login lockout threshold (e.g., 5 attempts)

# If using Cisco SD-WAN API:
# - Scope API service accounts to minimum required endpoints
# - Rotate API tokens immediately
# - Log and alert on API calls from unexpected source IPs

5. How to Test the Fix (Validation)

Since no patch exists yet, validation testing focuses on confirming compensating controls are effective.

Regression Test Scenarios

Scenario A: Verify management plane isolation

  • From a workstation outside the authorized management VLAN/CIDR, attempt to reach the SD-WAN Manager on port 443 (web UI), port 22 (SSH), and port 12346 (UDP/DTLS)
  • Expected result: All connections refused/dropped by firewall — none should reach the Manager

Scenario B: Verify netadmin account hygiene

  • Attempt to authenticate with a former employee's netadmin credentials (if known)
  • Expected result: Authentication fails — account disabled or credentials revoked

Scenario C: Verify MFA is enforced

  • Attempt to log in to a netadmin account using only username/password (no MFA token)
  • Expected result: Login rejected — MFA challenge presented and required

Scenario D: Verify unauthorized key removal

  • After removing any unauthorized SSH keys, attempt to authenticate to the vmanage-admin account using the key fingerprints identified during the audit step
  • Expected result: Authentication rejected — unauthorized key no longer accepted

Security Test Cases

Test Case 1: Validate DTLS port exposure

  • Precondition: Management plane isolated to out-of-band VLAN
  • Steps: Run nmap -sU -p 12346 <sdwan-controller-ip> from untrusted network
  • Expected Result: Port appears closed or filtered — not reachable from untrusted segments

Test Case 2: Validate log forwarding is active

  • Precondition: SIEM integration configured
  • Steps: Generate a test CLI login event, wait 60 seconds, query SIEM for the event
  • Expected Result: Event appears in SIEM within SLA window

Test Case 3: Confirm admin-tech output is preserved

  • Precondition: request admin-tech run before any changes
  • Steps: Verify output archive exists in offline storage with correct timestamp
  • Expected Result: Archive present, readable, and timestamped before any software updates

Automated Tests

#!/usr/bin/env python3
"""
SD-WAN Manager exposure validation script.
Tests whether management ports are correctly isolated.
Run from an UNTRUSTED network segment to validate compensating controls.
"""
import socket
import sys

SDWAN_MANAGER_IP = "<your-sdwan-manager-ip>"
MANAGEMENT_PORTS_TCP = [443, 22, 8443]  # Web UI, SSH, RESTCONF
MANAGEMENT_PORT_DTLS = 12346            # vdaemon/CVE-2026-20127 attack surface

def check_tcp_port(ip, port, timeout=3):
    try:
        s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
        s.settimeout(timeout)
        result = s.connect_ex((ip, port))
        s.close()
        return result == 0  # True = EXPOSED (bad)
    except Exception:
        return False

results = []
for port in MANAGEMENT_PORTS_TCP:
    exposed = check_tcp_port(SDWAN_MANAGER_IP, port)
    status = "❌ EXPOSED — ISOLATE IMMEDIATELY" if exposed else "✅ Not reachable"
    results.append((port, status))
    print(f"TCP {port}: {status}")

print("\nValidation complete. All ports should show 'Not reachable' from untrusted networks.")
if any(r[1].startswith("❌") for r in results):
    sys.exit(1)  # Fail CI/CD gate if management plane is exposed

6. Prevention & Hardening

Best Practices

  • Treat SD-WAN Manager as crown-jewel infrastructure. Apply the same access controls as a domain controller or core firewall — management access should require a jump host, MFA, and produce a full audit trail.
  • Never expose UDP 12346 (DTLS vdaemon) to untrusted networks. This port is the attack entry point for CVE-2026-20127 and CVE-2026-20182. Firewall rules should block it at the network perimeter and between corporate network zones.
  • Adopt a Zero Trust posture for SD-WAN management. The SD-WAN peering architecture's reliance on implicit network-level trust is the root cause of this entire CVE series. Require cryptographically verified device identity and continuous session validation at every SD-WAN controller interaction.
  • Maintain a minimal netadmin footprint. This privilege level should be held by no more than 2-5 named individuals with documented business need. Every account is a potential stepping stone for CVE-2026-20245.
  • Patch the entire 2026 CVE series, not just the latest. CVE-2026-20127, CVE-2026-20182, CVE-2026-20133, CVE-2026-20128, and CVE-2026-20122 all feed into the attack chain. A deployment that has patched some but not all of these remains exploitable.
  • Evaluate vendor risk posture. Seven zero-days in six months from a single product line mirrors the Pulse Secure VPN (2020-2021) and Citrix ADC (2019-2020) patterns — both of which preceded organizations abandoning the products entirely. Initiate a formal procurement review with your Cisco account team requesting a committed remediation roadmap and timeline.
  • For FedRAMP agencies: Begin Authorizing Official (AO) notification procedures immediately per FedRAMP incident handling requirements. Any KEV-listed or actively exploited vulnerability affecting an in-scope system triggers mandatory AO notification.

Monitoring & Detection

SIEM alerting rules to implement now:

# Rule 1: CLI file upload on SD-WAN Manager
alert:
  name: "Cisco SD-WAN Manager - Suspicious CLI File Upload"
  source: sdwan_manager_logs
  condition: |
    log_path = "/var/log/scripts.log" 
    AND message CONTAINS "vconfd_script_upload_tenant_list.sh"
    AND NOT src_ip IN authorized_mgmt_ips
  severity: Critical

# Rule 2: Public key authentication on vmanage-admin
alert:
  name: "Cisco SD-WAN - Unexpected SSH Key Auth on vmanage-admin"
  source: sdwan_auth_logs
  condition: |
    message CONTAINS "Accepted publickey for vmanage-admin"
    AND NOT src_ip IN authorized_mgmt_ips
  severity: Critical

# Rule 3: SD-WAN configuration push outside change window
alert:
  name: "Cisco SD-WAN - Config Push Outside Change Window"
  source: sdwan_audit_logs
  condition: |
    event_type = "configuration_template_push"
    AND NOT time_in_window("Mon-Fri 06:00-20:00 UTC")
  severity: High

# Rule 4: DTLS probe on UDP 12346 (CVE-2026-20127 attack vector)
alert:
  name: "Cisco SD-WAN - Unexpected DTLS Connection Attempt"
  source: network_firewall
  condition: |
    dst_port = 12346
    AND protocol = "UDP"
    AND NOT src_ip IN known_sdwan_controllers
  severity: High

Proactive threat hunting queries:

# Hunt for log clearing (UAT-8616 anti-forensics behavior)
index=sdwan host=<sdwan-manager-hostname>
| search "history -c" OR "rm /var/log/*" OR "truncate -s 0"
| table _time, user, command, src_ip

# Hunt for accounts created then immediately deleted
index=sdwan_audit event_type IN ("user_created","user_deleted")
| transaction user maxspan=1h
| where eventcount >= 2
| table _time, user, src_ip, events

References

Latest from the blog

See all →