What happened
On February 25, 2026, Cisco published security advisory cisco-sa-sdwan-rpa-EHchtZk about a critical flaw, CVE-2026-20127, in its Catalyst SD-WAN solution. This is the software companies use to centrally manage the network connecting their branches, data centers and cloud. The flaw sits in the control components: Catalyst SD-WAN Controller (formerly vSmart), Catalyst SD-WAN Manager (formerly vManage) and Catalyst SD-WAN Validator (formerly vBond).
According to Cisco, the mechanism these components use to authenticate each other does not work properly. That lets an attacker bypass the login and gain administrative privileges. Cisco has released fixed software and says there is no workaround that removes the flaw.
The flaw is already being actively exploited. The US agency CISA added it to its catalog of exploited vulnerabilities on February 25, 2026, the same day it was disclosed, and ENISA’s European vulnerability database EUVD records exploitation since that date. Cisco last updated the advisory on October 28, 2026 (version 2.1, Final).
Why it is dangerous
This is an authentication bypass (CWE-287). Picture a building where technicians let each other in based on a staff badge. If the badge reader is faulty, someone without a valid badge gets in too. That is essentially how authentication between the SD-WAN control components fails here.
The attacker needs no credentials and no help from any user. They only need network access to a vulnerable system so they can send it specially crafted requests. According to Cisco, they can then log in to the Controller as an internal, high-privileged account (though not root). Through that account they gain access to the NETCONF interface and can change the configuration of the entire SD-WAN network.
- CVSS is the standard severity scale from 0 to 10. Cisco itself assigned this flaw a score of 10.0 (CVSS 3.1). That is the maximum: a network attack, no login required, low complexity and high impact on confidentiality, integrity and availability.
- The CISA KEV (Known Exploited Vulnerabilities) catalog lists only flaws for which the US agency CISA has evidence of exploitation. It ordered US federal agencies to address this one by February 27, 2026, just two days later, pointing to its Emergency Directive 26-03 on Cisco SD-WAN systems.
- EPSS estimates the probability that a flaw will be exploited in the next 30 days. As of October 28, 2026, it stands at 89.3%, higher than 99.8% of all known vulnerabilities.
Who is affected
The flaw affects three Cisco Catalyst SD-WAN control components: Controller (vSmart), Manager (vManage) and Validator (vBond). According to Cisco, they are vulnerable regardless of how they are configured. Cisco lists the affected software releases in the Fixed Software table of its advisory. The following deployment types are affected:
- on-prem deployments in your own data center
- Cisco Hosted SD-WAN Cloud
- Cisco Hosted SD-WAN Cloud, Cisco Managed
- Cisco Hosted SD-WAN Cloud, FedRAMP environment
Catalyst SD-WAN is typically used by companies and organizations with multiple branches, and it is often run for them by an integrator or service provider. Cisco warns that systems with ports exposed to the internet are at risk of compromise. Cisco states that only the listed products are affected. If you do not use Cisco SD-WAN, this flaw does not concern you.
How to check if you are affected
First, find out whether Cisco Catalyst SD-WAN runs in your organization at all and who manages it. If a provider runs it for you, ask them directly whether the fix for CVE-2026-20127 has been applied.
You can see the version in the SD-WAN Manager web interface in the device list (Devices), which also includes the control components. On the command line of each component, this read-only command shows it:
show versionCompare the version with the Fixed Software table in Cisco advisory cisco-sa-sdwan-rpa-EHchtZk. Also review your firewall rules to see whether ports 22 (SSH) and 830 (NETCONF) on the control components are reachable from the internet or from unknown addresses.
How to fix it
The only permanent fix is upgrading to a fixed release. Cisco has released fixes and lists the specific release numbers for each software train in the Fixed Software section of its advisory. According to Cisco, there is no workaround that removes the flaw, only a temporary mitigation. Recommended order of steps:
- Inventory all control components (Controller, Manager, Validator) and their versions.
- If you run SD-WAN in your own data center, immediately restrict access to ports 22 and 830 with ACLs, security group rules or firewall rules so that only known controller IPs and other known addresses can connect. Cisco recommends allowing access to the control components only from hosts and devices that need it, following the Firewall Ports section of the Cisco Catalyst SD-WAN Getting Started Guide.
- Before upgrading, check for signs of compromise (see the next section) so you catch any intrusion as early as possible.
- Plan and perform the upgrade to the first fixed release according to Cisco’s table. Follow the vendor documentation for the order in which to upgrade the components.
- After upgrading, confirm the version with
show versionand check that all devices in the network have reconnected.
Cisco says these guardrails are already in place for all three Cisco Hosted SD-WAN Cloud variants (standard, Cisco Managed and FedRAMP). Cisco still lists the customer as the action owner, and for Cisco Managed the customer together with Cisco, so confirm the status with your Cisco contact.
Cisco notes that the mitigation proved successful in a test environment but may affect network functionality or performance. Assess the impact on your own environment before deploying it. CISA has also published Hunt & Hardening Guidance for Cisco SD-WAN Systems.
What if you may already be compromised
Cisco recommends auditing /var/log/auth.log for successful key-based logins of the vmanage-admin account (Accepted publickey) from unknown or unauthorized IP addresses. In the Linux shell of a control component (reach it from the CLI with vshell), this read-only command finds such entries, including in older and compressed rotated logs:
zgrep -h "Accepted publickey for vmanage-admin" /var/log/auth.log*Compare every IP address in the results against the System IP list in the SD-WAN Manager web interface (WebUI > Devices, System IP column). An address that is not on that list is a serious warning sign. Cisco also recommends manually validating every control connection peering event in the SD-WAN logs, especially vmanage peer types:
- Does the timing match a maintenance window, a configuration change or normal working hours?
- Does the public IP address belong to your organization or an authorized partner?
- Do the system IP and device type (vmanage, vsmart, vedge, vbond) match your topology?
- Are there repeated connections from the same address, and can they be matched to change records and admin activity?
If anything looks suspicious, open a case with Cisco TAC. Before doing so, Cisco recommends running request admin-tech on each control component to collect diagnostic data for support. If a compromise is confirmed, bring in an incident response specialist, because the attacker may have changed the configuration of your entire SD-WAN network.