CVSS 10.0: Cisco SD-WAN Auth Bypass Exploited in the Wild

Critically, Cisco's PSIRT stated in the advisory: "The Cisco PSIRT is aware of limited exploitation of this vulnerability." That single sentence changes everything. This is not a theoretical risk. Real attackers, whose identities remain unknown as of February 26, 2026, have already weaponized this flaw against production networks. CISA simultaneously listed CVE-2026-20127 in its KEV catalog and classified it as actively exploitable with "Automatable: Yes" and "Technical Impact: Total" under the Stakeholder-Specific Vulnerability Categorization (SSVC) framework — meaning scripted, automated attacks at scale are entirely feasible.

Understanding the Vulnerability

What Is Cisco Catalyst SD-WAN?

Before diving into the flaw itself, it helps to understand what's at stake. Cisco's Catalyst SD-WAN is a Software-Defined Wide-Area Network platform deployed by enterprises, government agencies, healthcare organizations, financial institutions, and critical infrastructure operators to connect distributed offices, data centers, and cloud environments. Think of it as the intelligent traffic controller for a company's entire inter-site network.

The two affected components play the most sensitive roles in the entire architecture:

• Catalyst SD-WAN Controller (vSmart): The control-plane brain of the SD-WAN fabric. It distributes routing policies and cryptographic key material to every edge device (vEdge/cEdge router) in the network. If an attacker controls this component, they control how every packet flows across the WAN.
• Catalyst SD-WAN Manager (vManage): The centralized management and orchestration platform. It provides the web dashboard, API, and configuration repository for the entire SD-WAN deployment. Compromise of this system gives an attacker a God-mode view and control over every router, policy, and VPN configuration in the fabric.

The Flaw: CWE-287 — Improper Authentication

The vulnerability is classified under CWE-287: Improper Authentication, a category describing situations where a system either fails to prove a user's identity at all, or does so with a mechanism that can be trivially bypassed. In this case, the flaw lives specifically in the peering authentication mechanism — the handshake process by which SD-WAN controllers authenticate and establish trusted relationships with one another and with the Manager.

Cisco's official description reads:

In plain language: the locks on the door between SD-WAN controllers don't actually work. An attacker can knock in just the right way and the system waves them through as a trusted administrator — no password, no certificate, no prior relationship required.

The Attack Chain: Step by Step

While Cisco has not publicly released the specific structure of the malformed peering request required for exploitation (and no public proof-of-concept code has been identified as of the date of this writing), the attack chain is well understood at a functional level:

Step 1 — Target Identification The attacker scans the internet for hosts listening on TCP port 830 (NETCONF over SSH) or TCP port 22 (SSH), which are the ports used by the SD-WAN peering and management interfaces on Catalyst SD-WAN Controller and Manager instances.

Step 2 — Crafted Peering Request The attacker sends a specially crafted request designed to exploit the broken peering authentication mechanism. Because the flaw affects the default configuration of these products — there are no non-standard settings required to be vulnerable — any reachable, unpatched instance is a viable target. The CVSS vector confirms this:

Breaking this down:

• AV:N — Attack Vector: Network (exploitable remotely over the internet)
• AC:L — Attack Complexity: Low (no special conditions or race conditions required)
• PR:N — Privileges Required: None (no existing account or credentials needed)
• UI:N — User Interaction: None (the victim doesn't need to click anything)
• S:C — Scope: Changed (the impact extends beyond the vulnerable component to the entire SD-WAN fabric)
• C:H / I:H / A:H — Confidentiality, Integrity, and Availability impact are all HIGH

This combination produces the maximum possible base score of 10.0.

Step 3 — Authentication Bypass The vulnerable peering authentication mechanism fails to properly validate the crafted request. The system accepts the attacker's connection as legitimate, bypassing all authentication controls.

Step 4 — Privileged Account Access The attacker is granted access as an internal, high-privileged, non-root user account — specifically surfacing in logs as the vmanage-admin account. This is not a low-privilege foothold. This is a highly privileged internal system account with broad access to management functions.

Step 5 — NETCONF Access With the vmanage-admin account, the attacker accesses the NETCONF (Network Configuration Protocol) interface. NETCONF, operating over SSH on port 830, is the programmatic interface used to read and write device configurations. Using NETCONF, an attacker can push arbitrary configuration changes to any device managed by the SD-WAN fabric.

Step 6 — Full SD-WAN Fabric Manipulation The attacker now has the keys to the kingdom. They can modify routing policies, VPN configurations, Quality of Service (QoS) rules, security policies, and the cryptographic key distribution that underlies the entire SD-WAN control plane — across every connected site and device in the deployment.

Why Port 830 (NETCONF) Matters

NETCONF is explicitly designed to be a machine-readable, fully programmable interface for bulk network configuration. Unlike a web dashboard that requires human interaction, NETCONF interactions can be fully scripted and automated. An attacker with NETCONF access can enumerate all device configurations, extract credentials stored within them, push malicious routing changes to hundreds of sites simultaneously, and do all of this programmatically in a matter of minutes. This is precisely why CISA's SSVC classification rates the exploit as "Automatable: Yes" — once the authentication bypass is achieved, everything that follows can be scripted at scale.

Who Is Affected

The scope of affected versions is extraordinarily wide. The CVE JSON data from Cisco's CNA entry lists over 250 individual version strings for the Catalyst SD-WAN Manager alone, spanning from version 17.2.4 all the way through 20.18.2. The following table consolidates the affected release trains and their corresponding fixed versions:

Notable specific affected versions from the official CVE data include (but are not limited to): 17.2.4, 17.2.5, 17.2.6, 17.2.7, 17.2.8, 17.2.9, 17.2.10, 18.2.0, 18.3.0, 18.3.1, 18.3.3, 18.3.4, 18.3.5, 18.3.6, 18.3.7, 18.3.8, 18.4.0, 18.4.1, 18.4.3, 18.4.4, 18.4.5, 18.4.6, 19.0.0, 19.0.1a, 19.1.0, 19.2.0, 19.2.1, 19.2.2, 19.2.3, 19.2.4, 19.3.0, 20.1.1, 20.1.2, 20.1.3, 20.3.x (all subversions through 20.3.8), 20.4.x (all subversions), 20.5.x, 20.6.x (all subversions through 20.6.8), 20.7.x, 20.8.1, 20.9.x (all subversions through 20.9.8 and associated LI_Images variants), 20.10.x, 20.11.x, 20.12.x (through 20.12.6 and associated LI_Images variants), 20.13.x, 20.14.x, 20.15.x (through 20.15.4.1), 20.16.x, 20.18.1, 20.18.2, and all associated LI_Images variants of the above.

Important deployment context: Cisco customers running cloud-hosted instances managed by Cisco (including FedRAMP-authorized deployments) have already had mitigating controls applied by Cisco directly. Those customers should confirm their status with Cisco but are not the primary population at risk. On-premises deployments — where the customer manages their own SD-WAN Controller and Manager instances — are at the highest risk and must take immediate manual action.

Real-World Risk

Active Exploitation Confirmed

Cisco's PSIRT has confirmed that exploitation is occurring in the wild as of the advisory publication date of February 25, 2026. The phrase used — "limited exploitation" — is consistent with the early stages of a targeted campaign, but the combination of a CVSS 10.0 score, trivial exploit complexity, and the availability of what appears to be a working exploit technique means that "limited" is a word that has a very short shelf life. History has repeatedly shown that once a maximum-severity, authentication-bypass vulnerability in widely deployed network infrastructure is confirmed exploited in the wild, the volume of exploitation attempts escalates dramatically within days.

CISA's SSVC assessment classified the exploit as "Automatable: Yes" — meaning threat actors can build scanners and exploit frameworks that automatically identify and compromise vulnerable instances at internet scale without human intervention for each target. Think of it as the difference between a burglar who tries one door at a time versus a machine that simultaneously tries every door on every street in the world.

Who The Attackers Could Be

As of February 26, 2026, no specific threat actor groups or named campaigns have been publicly attributed to exploitation of CVE-2026-20127. CISA lists the ransomware use status as "Unknown." However, the target profile — centralized network management infrastructure for enterprises and government agencies — is precisely the type of high-value target that attracts both financially motivated ransomware groups and nation-state actors engaged in espionage or pre-positioning for destructive attacks.

The involvement of the Australian Signals Directorate's Australian Cyber Security Centre in reporting this vulnerability is notable. The ASD/ACSC is Australia's signals intelligence and cybersecurity agency, operating within the Five Eyes intelligence alliance. Their involvement in discovering and reporting this flaw suggests it may have been identified through threat intelligence activities, potentially meaning it was observed being exploited by sophisticated actors before the public advisory was issued.

Worst-Case Scenarios

If an attacker successfully exploits CVE-2026-20127 against an organization's on-premises SD-WAN infrastructure, the potential consequences are severe and far-reaching:

Traffic Interception and Espionage: By manipulating routing policies through NETCONF, an attacker can redirect traffic flows through attacker-controlled infrastructure, enabling passive interception of all unencrypted (and potentially encrypted, via man-in-the-middle attacks) data traversing the WAN. For organizations with SD-WAN connecting offices, hospitals, financial branches, or government facilities, this represents a total loss of data confidentiality.

Configuration Tampering and Persistence: An attacker with NETCONF access can push malicious configurations to every managed edge device simultaneously. These configurations can create persistent backdoors, disable security controls, modify VPN parameters, and alter access control lists across hundreds of sites in a single programmatic operation.

Traffic Redirection for Further Attacks: Modified routing policies can be used to redirect specific traffic flows — for example, directing authentication traffic through a rogue DNS server, or routing internal management traffic to an attacker-controlled system — facilitating credential harvesting and lateral movement into otherwise segmented networks.

Ransomware Propagation: By gaining control of the routing fabric and disabling network segmentation controls, ransomware operators can dramatically accelerate the spread of encryption malware across geographically distributed sites, maximizing the scope of damage before defenders can respond.

Wide-Area Network Denial of Service: An attacker can simply destroy WAN connectivity across an organization's entire footprint by pushing invalid or contradictory routing configurations, effectively taking down inter-site communications for every connected location simultaneously.

Credential Extraction: SD-WAN Manager stores configuration data that includes authentication credentials and cryptographic material for managed devices. An attacker with administrative NETCONF access can extract this material, gaining footholds into every device managed by the compromised Controller or Manager.

What You Should Do

Given that exploitation is actively occurring and CISA has issued an Emergency Directive, the response posture must be treated as an incident response situation, not a routine patch management exercise.

Immediate Actions (Do These Now, Before Patching)

1. Implement Network-Level ACLs Immediately

If you cannot patch right now, the single most important mitigation is to restrict inbound access to the vulnerable ports to known, trusted IP addresses only. Apply Access Control Lists (ACLs) or firewall rules to block all traffic to TCP port 22 (SSH) and TCP port 830 (NETCONF) from any IP address that is not a known, authorized SD-WAN Controller or trusted management station.

Critical caveat: ACLs must be scoped precisely. If they are too broad or misconfigured, legitimate controller-to-controller communication and management operations will break. Document all operational source IPs before deploying these rules. This is a partial mitigation only — it reduces the attack surface but does not fix the underlying vulnerability.

2. Audit Authentication Logs for Signs of Compromise

Before assuming your environment is clean, check for indicators of compromise. Examine /var/log/auth.log on all SD-WAN Controller and Manager instances for the following pattern:

Any IP address appearing in this log entry that is not a recognized, authorized controller IP in your SD-WAN topology is a strong indicator of compromise. Cross-reference these IP addresses against your SD-WAN Manager's configured System IPs (accessible via WebUI > Devices > System IP). Unknown IPs in this log are a red flag that demands immediate escalation.

3. Audit Peering Events

Review peering logs for vmanage peer types originating from unexpected IP addresses. Specifically look for:

• Peering events occurring outside scheduled maintenance windows
• Peering events where the peer-system-ip does not match any device in your SD-WAN topology
• Unrecognized public IP addresses appearing in peering logs

Patching: Apply Fixed Releases Immediately

The following fixed software versions are available. Upgrade to the appropriate version for your current release train:

All patches are available through Cisco's Software Center. The official advisory URL for patch downloads and verification is: https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-sdwan-rpa-EHchtZk

For customers on the 20.9.x release train: The fix (20.9.8.2) has an estimated release date of February 27, 2026 — the same day as the CISA Emergency Directive deadline. This is a genuine race condition. If your organization operates on the 20.9.x train and cannot wait for 20.9.8.2, evaluate whether upgrading to a parallel fixed train (such as 20.12.5.3 or 20.12.6.1) is feasible given your hardware and feature requirements. Regardless, implement ACL mitigations immediately while awaiting the 20.9.8.2 release.

For customers on release trains with no direct fix listed (20.11, 20.13, 20.14, 20.16): These trains do not have direct point-release fixes listed. You must upgrade to a fixed release train. Consult the full Cisco advisory and Cisco TAC for guidance on the appropriate migration path.

Detection Rules

Cisco has published Snort intrusion detection rules for this vulnerability. If you operate a Snort-based IDS/IPS (including those embedded in Cisco Firepower/FTD), ensure your rule sets are updated and specifically verify the following rules are active and generating alerts:

• Snort Rule 65938
• Snort Rule 65958

If Compromise Is Suspected

If your log review reveals indicators of compromise, do not simply patch and move on. A compromised SD-WAN Controller or Manager may have been used to push malicious configurations to edge devices across your entire WAN. The following steps should be taken:

1. Isolate the compromised Controller or Manager from the network immediately.
2. Execute request admin-tech on all control plane components (Controllers and Manager) and submit the resulting diagnostic bundle to Cisco TAC immediately. This command collects comprehensive diagnostic data that Cisco engineers need to assess the scope of compromise.
3. Audit all SD-WAN edge device configurations for unauthorized changes, focusing on routing policies, VPN configurations, access control lists, and any newly created user accounts or credentials.
4. Engage your incident response team and consider whether CISA's "Hunt & Hardening Guidance for Cisco SD-WAN Devices" (referenced in Emergency Directive 26-03) should be used to guide the investigation.
5. Do not reuse credentials that were stored in or processed by the compromised Manager instance.

Compliance Note: CISA Emergency Directive 26-03

For U.S. Federal Civilian Executive Branch (FCEB) agencies, CISA Emergency Directive 26-03 mandates remediation by February 27, 2026. All FCEB agencies must adhere to this directive and should also consult CISA's published "Hunt & Hardening Guidance for Cisco SD-WAN Devices" as part of their response.

The Bigger Picture

CVE-2026-20127 is not just another enterprise software vulnerability. It represents something more structurally concerning: a maximum-severity, authentication-bypass flaw in the very infrastructure layer that enterprises and governments trust to securely connect their distributed operations. SD-WAN was sold — correctly — as a way to simplify and centralize WAN management. That centralization is now a liability when the management plane itself is compromised.

This is at least the second major critical vulnerability to affect Cisco's SD-WAN product line in recent years, and the pattern is worth noting. Centralized network management platforms are enormously attractive targets precisely because of their reach: a single compromised Controller or Manager can cascade impact across every site, device, and user in an organization's WAN footprint. The architectural principle that makes SD-WAN operationally efficient — centralized control — is the same principle that makes a vulnerability in that control plane catastrophically dangerous.

The involvement of a Five Eyes signals intelligence agency (ASD/ACSC) in the discovery of this vulnerability, combined with Cisco's confirmation of active exploitation prior to the public advisory, raises a question that remains unanswered as of this writing: how long were attackers exploiting this before the patch was ready? The Cisco advisory lists the CVE reservation date as October 8, 2025 — meaning the vulnerability was reserved in the CVE system over four months before patches were made available to customers. The advisory does not specify when exploitation began relative to the patch development timeline, and this gap represents a significant intelligence uncertainty.

Organizations should watch for:

• Further technical analysis of the peering authentication bypass mechanism as security researchers reverse-engineer the patches released on February 25, 2026
• Public proof-of-concept code, which historically emerges within days to weeks after patches for high-severity authentication bypasses are released
• Attribution of the threat actors currently exploiting this vulnerability — their identity and objectives will inform whether this is a financially motivated campaign, a state-sponsored espionage operation, or both
• CISA's Hunt & Hardening Guidance for additional detection techniques and hardening recommendations beyond what is contained in the initial advisory
• Related vulnerabilities in other SD-WAN peering and control-plane authentication mechanisms across competing vendors, as vulnerability research in one platform often stimulates parallel research in others

The bottom line is stark: if your organization runs Cisco Catalyst SD-WAN Controller or Manager on-premises and you have not yet implemented ACL restrictions on ports 22 and 830 and begun your patching process, you are operating vulnerable internet-facing infrastructure that attackers are demonstrably and actively exploiting today. The patch is available. The workaround is documented. The indicators of compromise are specific and actionable. Every hour of delay is an hour of unnecessary exposure.

See advisory