CVE-2026-20182: Critical authentication bypass in Cisco Catalyst SD-WAN Controller (FIXED)

Overview While researching a critical authentication bypass vulnerability, CVE-2026-20127 , which was exploited in-the-wild , Rapid7 Labs discovered a new authentication bypass vulnerability affecting Cisco Catalyst SD-WAN Controller (formerly known as vSmart), CVE-2026-20182 . This new authentication bypass vulnerability affects the “vdaemon” service over DTLS (UDP port 12346), which is the same service that was vulnerable to CVE-2026-20127. The new vulnerability is not a patch bypass of CVE-2026-20127. It is a different issue located in a similar part of the “vdaemon” networking stack. This impact however is the same, a remote unauthenticated attacker can leverage CVE-2026-20182 to become an authenticated peer of the target appliance, and perform privileged operations , such as injecting an attacker controlled public key into the vmanage-admin user account’s authorized SSH keys file. Once this has been performed, a remote unauthenticated attacker can login to the NETCONF service (SSH over TCP port 830) as the vmanage-admin user, and begin to issue arbitrary NETCONF commands. CVE-2026-20182 has a CVSSv3.1 score of 10.0 (Critical), and a Common Weakness Enumeration (CWE) of CWE-287 : Improper Authentication. Technical analysis The Cisco Catalyst SD-WAN Controller serves as the central control plane. Unlike Cisco Catalyst SD-WAN Manager, it has no web UI. Its network-reachable attack surface is narrow and depending on the configuration may expose the following ports: Port Protocol Service 22 TCP SSH (OpenSSH) 830 TCP NETCONF over SSH 12346 UDP vdaemon DTLS control plane ⠀ UDP port 12346 is the DTLS-over-UDP control-plane peering port used by vdaemon for inter-controller and controller-to-edge communication. It carries Overlay Management Protocol (OMP) messages including route advertisements, Transport Locations (TLOC) tables, and peer state - the entirety of the SD-WAN overlay routing fabric. Compromising this service means compromising the network. To understand the vulnerability, we first need to understand how vdaemon authenticates control-plane peers. The protocol is a multi-phase handshake over DTLS: Attacker vSmart | | |──── DTLS Handshake (any cert) ───────────>| ← cert verify logs error but returns OK | | | | ← device_type=2 (vHub) → NO VERIFICATION | | | authenticated = 1 | | |──── Hello (msg_type=5) ──────────────────>| ← passes auth check, peer goes UP | | | authenticated = true // authenticated = true”, and returns success. The authenticated flag at peer struct offset 70 is the single bit that gates all subsequent message processing. The following table summarizes the verification applied to each device type: Device Type Value Verification Result vEdge 1 HW cert, challenge signature, board ID, OTP Verified vHub 2 None Falls through to “peer->authenticated = 1” vSmart 3 Cert chain, serial lookup, duplicate check Verified vBond 4 N/A (trust anchor - handled elsewhere) - vManage 5 Cert chain, serial lookup, duplicate check Verified ⠀ Therefore, a remote unauthenticated attacker can bypass authentication by connecting to the vSmart DTLS port with any self-signed client certificate and claiming to be a vHub (type 2) in the CHALLENGE_ACK message . No valid credentials, no CA-signed certificate, and no knowledge of the SD-WAN deployment are required. Looking further at the message dispatcher, we need to confirm that the CHALLENGE_ACK message can actually reach vbond_proc_challenge_ack() without prior authentication. The answer is in the pre-dispatch authentication gate in vbond_proc_msg() : // vdaemon!vbond_proc_msg() // Pre-dispatch authentication gate: if ( *(_BYTE *)(v100 + 70) != 1 // authenticated = true” via the vHub bypass, the attacker must send a Hello message (Message type 5) to transition the peer to the UP state. The Hello handler has its own secondary authentication check: // Case 5 (Hello) in vbond_proc_msg - line 20362 case 5: // ...snip... if ( *(_BYTE *)(v100 + 70) != 1 ) // authenticated == true” before processing. After our exploit sets this flag via the vHub bypass, Hello passes this secondary check and the peer transitions to the UP state, a fully trusted control-plane peer. Putting all the pieces together: the attack chain is DTLS handshake (any cert) → receive CHALLENGE → send CHALLENGE_ACK with device type 2 (vHub) → authentication flag set unconditionally → send Hello → peer transitions to UP. After establishing as an authenticated peer, the attacker has access to the full range of control-plane message types. We identified a particularly impactful post-authentication primitive: persistent SSH key injection via MSG_VMANAGE_TO_PEER (Message type 14). The handler for message type 14 is vbond_proc_vmanage_to_peer() . Examining the decompiled code: // vdaemon!vbond_proc_vmanage_to_peer() // ...snip... stream = fopen("/home/vmanage-admin/.ssh/authorized_keys", "a+"); // 6 ) syslog( 191, "%s[%d]: %%%s-%d: sshkey not present, writing to file", "vbond_proc_vmanage_to_peer", 2368LL, aVdaemonDbgMisc, 7LL); fputs((const char *)(a3 + 32), stream); // set RHOSTS 192.168.80.11 msf6 auxiliary(admin/networking/cisco_sdwan_vhub_auth_bypass) > run ⠀ Figure 2: Module output showing the vHub authentication bypass and SSH key injection ⠀ The attacker can now SSH into the NETCONF service over TCP port 830 by running the following command (as instructed by the exploit above). ssh -i /home/cryptocat/.msf4/loot/20260501115947_default_192.168.80.11_cisco.sdwan.sshk_491665.pem vmanage-admin@192.168.80.11 -p 830 ⠀ SSH public key authentication will succeed, and the attacker will have successfully established a connection to the NETCONF service. Figure 3: Successful SSH connection to the NETCONF service as vmanage-admin ⠀ At this point the attacker can begin to execute arbitrary NETCONF commands, for example the following “get-config” command can be run by the attacker in the NETCONF session. urn:ietf:params:netconf:base:1.0 ]]>]]> ]]>]]> ⠀ The output of the get-config command is shown below. Figure 4: NETCONF get-config output from the compromised controller ⠀ The full Metasploit module will be made available on May 27, 2026. Remediation Cisco has released software updates that address this vulnerability. There are no workarounds that address this vulnerability. Customers are advised to upgrade to an appropriate fixed software release as indicated in the Fixed Software section of the Cisco Security Advisory. The following tables indicate the appropriate fixed software releases. Cisco Catalyst SD-WAN Release First Fixed Release Earlier than 20.9* Migrate to a fixed release 20.9 20.9.9.1 20.10 20.12.7.1 20.11* 20.12.7.1 20.12 20.12.5.4, 20.12.6.2, 20.12.7.1 20.13* 20.15.5.2 20.14* 20.15.5.2 20.15 20.15.4.4, 20.15.5.2 20.16* 20.18.2.2 20.18 20.18.2.2 26.1.1 26.1.1.1 *These releases have reached the end of software maintenance . Cisco strongly encourages customers to upgrade to a supported release . For additional details, please see the vendor advisory . Vendor statement "Cisco values the role of the security research community in helping maintain a secure ecosystem and we appreciate the collaboration with Rapid7. We have released a software update to remediate the identified vulnerability. We remain committed to transparent communication and to providing our customers with the robust security and resilience they expect." Rapid7 customers Exposure Command, InsightVM and Nexpose customers will be able to assess their exposure to CVE-2026-20182 with an authenticated vulnerability check expected to be available in the May 14th, 2026 content release. Credit This vulnerability was discovered by Stephen Fewer, Senior Principal Security Researcher, and Jonah Burgess, Senior Security Researcher, both at Rapid7 and is being disclosed in accordance with Rapid7’s vulnerability disclosure policy . Disclosure timeline March 9, 2026: Rapid7 makes initial outreach to Cisco who confirms contact the same day. Rapid7 discloses the technical writeup and exploit code to Cisco. March 11, 2026: Cisco confirms receipt of the technical writeup and exploit code and suggests a disclosure date of May 7, 2026. March 20, 2026: Cisco confirms the vulnerability findings, and that a CVE will be reserved. April 21, 2026: Cisco provides reserved CVE identifier and remediation guidance. April 24, 2026: Cisco provides remediation version numbers, alignment on CWE and CVSS scoring, and requests moving disclosure date to May 14. May 14, 2026: This disclosure.