Cisco Catalyst SD-WAN Controller Flaw CVE-2026-20182 Scores Perfect
Rapid7 discovered CVE-2026-20182, a 10.0-CVSS authentication bypass in Cisco Catalyst SD-WAN Controller. Unauthenticated attackers can inject SSH keys and issue NETCONF commands.

Executive Summary
Rapid7 Labs has disclosed a critical authentication bypass vulnerability in the Cisco Catalyst SD-WAN Controller (formerly vSmart), tracked as CVE-2026-20182, with a perfect CVSSv3.1 score of 10.0. The flaw resides in the vdaemon service listening on UDP port 12346 and allows a remote, unauthenticated attacker to impersonate a trusted peer, inject an attacker-controlled SSH public key into the vmanage-admin account, and then issue arbitrary NETCONF commands over SSH on TCP port 830. According to Rapid7's analysis, the vulnerability was discovered while investigating a separate in-the-wild exploited flaw, CVE-2026-20127, and is not a patch bypass but an independent issue in a similar code path. Cisco has released a fixed software version; affected organizations should prioritize patching immediately.
Technical Analysis
The Cisco Catalyst SD-WAN Controller serves as the central control plane for SD-WAN fabrics, managing overlay routing via the Overlay Management Protocol (OMP). Unlike the Catalyst SD-WAN Manager, it has no web interface, exposing a narrow attack surface: SSH (TCP 22), NETCONF over SSH (TCP 830), and the vdaemon DTLS control-plane service (UDP 12346). Compromising the vdaemon service effectively grants control over the entire SD-WAN overlay routing fabric.
Rapid7's reverse engineering of the vdaemon binary reveals the vulnerability in the vbond_proc_challenge_ack() function, which processes the CHALLENGE_ACK message during the DTLS handshake. The handshake proceeds as follows:
- The attacker completes a DTLS handshake with the controller, which accepts any client certificate.
- The controller sends a CHALLENGE (msg_type=8) containing 256 random bytes and TLVs including CA RSA public key components.
- The attacker responds with a CHALLENGE_ACK (msg_type=9), setting
device_type=2(vHub) in the message header. - The controller sends a CHALLENGE_ACK_ACK (msg_type=10) and sets
peer->authenticated = 1. - The attacker sends a Hello (msg_type=5) and the peer is marked UP.
The 12-byte vdaemon message header encodes the device type in the upper nibble of byte 1. The protocol defines device types: vEdge (1), vHub (2), vSmart (3), vBond (4), vManage (5), and ZTP (6). The critical flaw is that the verification logic in vbond_proc_challenge_ack() contains conditional blocks for device types 1 (vEdge), 3 (vSmart), and 5 (vManage), but has no code path for device type 2 (vHub). As a result, when a peer claims to be a vHub, the function skips all certificate verification and proceeds directly to setting peer->authenticated = true at offset [6] in the decompiled code.
The decompiled pseudocode shows:
- At [1], the function checks if the connecting peer claims to be vSmart (type 3) or vManage (type 5) and performs serial number duplicate checks.
- At [3], additional certificate and state checks occur for specific combinations of peer and local device types.
- At [4], vEdge (type 1) peers undergo hardware/virtual edge certificate verification.
- At [5], there is no conditional block for device_type == 2 (vHub), meaning the function falls through to [6] where
peer->authenticatedis set to true without any verification.
Once authenticated, the attacker can inject an SSH public key into the vmanage-admin account's authorized_keys file, then log in to the NETCONF service (SSH on TCP 830) and execute arbitrary NETCONF commands. The vulnerability is classified under CWE-287 (Improper Authentication).
Rapid7 explicitly states that CVE-2026-20182 is not a patch bypass of CVE-2026-20127, which was exploited in the wild. Both affect the same vdaemon service but are distinct issues in different parts of the networking stack.
Mitigations & Recommendations
Cisco has released a fixed software version for the Catalyst SD-WAN Controller. Organizations running affected versions should apply the update as soon as possible, prioritizing devices exposed to untrusted networks. As a compensating control, network administrators can restrict UDP port 12346 access to only known, trusted SD-WAN peers using firewall rules or access control lists. Monitor NETCONF logs for unauthorized SSH key additions or unexpected commands. Rapid7 notes that the vulnerability is remotely exploitable without authentication, making unpatched controllers a high-priority target.
Stay Updated
Get the latest cybersecurity news delivered to your inbox.
