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 | | | ──── CHALLENGE (msg_type=8) ──────────────│ ← 256 random bytes + TLVs | | |──── CHALLENGE_ACK (msg_type=9) ────────── | ← device_type=2 (vHub) → NO VERIFICATION | | | ──── CHALLENGE_ACK_ACK (msg_type=10) ─────│ ← peer- authenticated = 1 | | |──── Hello (msg_type=5) ────────────────── | ← passes auth check, peer goes UP | | | ──── Hello (msg_type=5) ──────────────────│ ← peer-type:vhub, new-state:up ⠀ After a DTLS handshake completes (which accepts any client certificate), the server sends a CHALLENGE containing 256 random bytes and a set of TLVs including Certificate Authority (CA) RSA public key components. The client must respond with a CHALLENGE_ACK , and it is during the processing of this response, in vbond_proc_challenge_ack() , t