Cisco Catalyst SD-WAN Manager CVE-2026-20245 exploitation briefing

CVE-2026-20245 matters as a control plane compromise that can lead to root access on Cisco Catalyst SD-WAN control components. 

The issue affects the CLI in Cisco Catalyst SD-WAN Controller, Manager, and Validator, which were formerly known as vSmart, vManage, and vBond. Cisco describes it as an authenticated local privilege escalation. An attacker with netadmin privileges can submit a crafted file, trigger command injection, and run commands as root. 

That access requirement changes how the case should be read. In most cases, this is a second-stage issue rather than the first move. The attacker already needs a foothold, whether through valid credentials, compromised credentials, or an earlier SD-WAN authentication bypass weakness. Cisco has not described broad exploitation through other paths, but it has seen limited cases where attackers used this access to push configuration changes to edge devices. 

Prioritize systems exposed to untrusted management networks, the ones showing rogue peering or unusual SSH activity, and the ones with suspicious tenant upload activity on control components. 

Collect evidence before patching. Cisco says collecting admin-tech from all control components before making upgrades or configuration changes. Patching closes the hole, but it doesn’t answer whether the control plane was already used.

What the activity looks like

Cisco’s account is consistent. CVE-2026-20245 requires netadmin privileges. Attackers can get there with valid credentials or by using earlier SD-WAN authentication bypass issues, including CVE-2026-20127 and CVE-2026-20182. The vulnerability becomes dangerous once the control plane is already in play. 

The intrusion chain described in the reporting starts with unauthorized peering activity. After that, the attacker authenticated over SSH, changed the default admin password to access the web application, pulled configuration data, and then used the tenant upload workflow to process a crafted file named evil_tenant.csv. That file added a root-level account named troot to /etc/passwd and /etc/shadow. The attacker then used su to move from admin into troot. The reporting also leaves room for uncertainty. Not every rogue peering event may have come from the same actor, and one later phase may have relied on certificate material stolen earlier. 

The attack path leaves evidence, but it is not always definitive. It can appear in SSH logs, password change events, rollback deltas, su activity, script logs, and command history. Some artifacts can overlap with normal administration, so each hit must be checked in context. Cisco notes that scripts.log entries can appear during routine work, which means defenders need to compare them against normal operating patterns before calling them compromise. 

The flow is direct: the attacker gains control-plane access, uses CVE-2026-20245 to escalate privileges, and in some cases pushes changes to edge devices. 

How the chain unfolds

Why this matters

Cisco Catalyst SD-WAN Controller, Manager, and Validator sit close to routing policy, templates, certificates, and edge onboarding. Root access on one control component can affect more than the local host. It can put routing policy, device trust, and edge configuration at risk. 

The report says configuration data was pulled from the management role, and Cisco’s remediation notes mention limited cases where attackers pushed changes to edge devices. This should not be treated like a routine local privilege escalation ticket. 

Patching closes the vulnerability, but it does not show whether the system was already used. In the case Cisco described, the attacker deleted the CSV file, restored modified files, and checked whether the troot account and backup files were still present. Once root access and cleanup show up together, the response should move into incident handling. 

Do not stop at the manager’s role. The affected scope includes SD-WAN control components, so controller and validator logs belong in the first evidence to pull as well. Looking only at the manager can miss parts of the chain.

What to check first

Exposure and access: Confirm which control-plane components were reachable from the internet or other untrusted paths. Review rogue peer events and unauthorized peering attempts. Check SSH logins to privileged accounts from source IPs that do not match normal management ranges. 

Identity and local state: Look for quick password changes and reversions affecting admin. Inspect /var/confd/rollback/ for commits that touch local user passwords. Check for successful su from admin to troot and for hidden backup files under /home/admin/. 

Evidence collection: Collect request admin-tech output from every control-plane component before upgrades or configuration changes. If the artifacts line up, or if they cannot be explained, open a support case with the platform provider and preserve the diagnostic bundles. Upgrade after evidence is secured. Then rotate local credentials and secrets, review configuration templates, verify edge-device configuration, and re-onboard affected edge devices if their state cannot be trusted.

Affected Scope

The affected scope covers SD-WAN control components regardless of deployment model. That includes: 

• SD-WAN controller role. 

• SD-WAN manager role. 

• SD-WAN validator role. 

On-premises, provider-hosted, provider-managed cloud, government, and regulated cloud environments all need the same triage questions.

Fixed Releases

Securonix Threat Labs Summary

Securonix Threat Labs recommends implementing the following defensive measures to strengthen security posture and mitigate potential risks.

Detection focus

Securonix Threat Labs recommends organizations to use these checks as leads. Some of them can be normal during administration. Tie each hit to timing, source IP, account, host role, and nearby activity before calling it compromise.

• Unexpected SSH sessions: Monitor authentication logs, usually /var/log/auth.log, for privileged logins from external or unfamiliar source IPs.

Jan 01 07:58:00 sdwan-manager sshd[20766]: Accepted publickey for <control-admin> from <actor_ip> port 48373 ssh2 
Jan 01 08:01:00 sdwan-manager sshd[25178]: Accepted keyboard-interactive/pam for admin from <actor_ip> port 60552 ssh2 

• Password changes close together: Look for admin password changes that are set and then reverted shortly after, especially when they sit near unexpected SSH access or tenant upload activity.

Jan 01 08:00:00 sdwan-manager usermod[12345]: change user 'admin' password 
Jan 01 08:15:00 sdwan-manager usermod[12345]: change user 'admin' password 

• Rollback deltas involving local users: Inspect rollback files under /var/confd/rollback/ for commits that touch local user credentials.

# Created by: <control-admin> 
# Date: 2026-01-01 08:00:00 
# Via: netconf 
# Type: delta 
# No: 10000 
# TransactionId: 12345678 
# Hostname: sdwan-manager 
system { 
aaa { 
user admin { 
password <redacted>; 
} 
} 
} 

• Successful su into an unauthorized root account: Search system logs and terminal history for successful su activity from admin into troot or any other local account that does not fit a known operational need.

Jan 01 08:03:00 sdwan-manager su[24289]: Successful su for troot by admin

• Tenant upload script execution: Search script logs for the tenant upload workflow and for file paths that point to unknown CSVs under /home/admin/. 

Jan 01 08:01:05 sdwan-manager vScript: Tenant list upload per controller serial number: 
/usr/bin/vconfd_script_upload_tenant_list.sh -cli path /home/admin/evil_tenant.csv vpn 0 
Jan 01 08:01:05 sdwan-manager vScript: uploading tenant list via VPN 0 true 
Jan 01 08:01:05 sdwan-manager vScript: Copying /home/admin/evil_tenant.csv via VPN 0 
Jan 01 08:01:05 sdwan-manager vScript: Successfully loaded the tenant placement file

• Command history pivot: This command is useful when it shows up near the rest of the activity.

01-01 08:01:05 : request tenant-upload tenant-list /home/admin/evil_tenant.csv vpn 0

Analyst note

This bug is easy to underplay because it is local and authenticated. The mistake is to look only for evil_tenant.csv, find nothing, and close the ticket. In the case described, that file was deleted. The better approach is to follow the sequence: rogue peering, a new SSH source, a quick admin password change, tenant upload, troot, and cleanup. One event by itself may be normal. Several of them in a short window should push the case into incident response.

Indicators of Compromise (IOCs)

References

1. NVD - CVE-2026-20245 - https://nvd.nist.gov/vuln/detail/CVE-2026-20245 

2. Zero-Day Exploitation of Vulnerability (CVE-2026-20245) in Cisco Catalyst SD-WAN Manager | Google Cloud Blog - https://cloud.google.com/blog/topics/threat-intelligence/zero-day-exploitation-cisco-catalyst-sd-wan-manager/ 

3. Remediate Catalyst SD-WAN Security Advisory - June 2026 – Cisco - https://www.cisco.com/c/en/us/support/docs/routers/sd-wan/226014-remediate-catalyst-sd-wan-security.html 

4. Cisco Catalyst SD-WAN Controller, Catalyst SD-WAN Manager, and Catalyst SD-WAN Validator Authenticated Privilege Escalation Vulnerability - https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-sdwan-privesc-4uxFrdzx