This is a fake badge at the SD-WAN air-traffic-control tower
CVE-2026-20182 is an authentication bypass in Cisco Catalyst SD-WAN Controller and Manager vdaemon peering over DTLS/UDP 12346. Per Cisco, it affects Controller and Manager across on-prem, Cloud-Pro, Cisco-managed cloud, and FedRAMP deployments regardless of configuration, with fixed releases at 20.9.9.1, 20.12.5.4, 20.12.6.2, 20.12.7.1, 20.15.4.4, 20.15.5.2, 20.18.2.2, 26.1.1.1, and Cisco-managed cloud 20.15.506.
Cisco’s 10.0 is directionally right because the bug sits on the control plane and lets an unauthenticated attacker become a trusted peer, then pivot into vmanage-admin/NETCONF-level control. I shave it only slightly because the exposed population is much smaller than a generic internet-facing web app: many enterprises do not expose SD-WAN controllers broadly, but the ones that do are holding a crown-jewel blast radius.
4 steps from start to impact.
Find a reachable controller or manager
12346, not the web UI. Public recon or existing foothold visibility is enough to identify a Controller/Manager that answers on the peering port; Cisco explicitly says internet-exposed controllers with exposed ports are at risk.- Unauthenticated remote network access to UDP
12346on Cisco Catalyst SD-WAN Controller or Manager - Target running an affected release
- Many enterprises keep controllers off the public internet or tightly ACL the peering path
- Only a narrow product subset is affected compared with commodity perimeter software
12346; authenticated VM checks from Rapid7 were published for May 14, 2026 content.Spoof a vHub during DTLS peering with admin/networking/cisco_sdwan_vhub_auth_bypass
vbond_proc_challenge_ack() path accepts a CHALLENGE_ACK claiming device type 2 (vHub) after a DTLS handshake with any self-signed certificate. That code path performs no certificate or credential verification for vHub and falls through to peer->authenticated = 1.- Target service reachable on UDP
12346 - Attacker can complete a DTLS handshake and send crafted protocol messages
- This is not browser-click exploitation; it requires protocol-aware tooling
- Middleboxes that block or rate-limit unusual DTLS peering can disrupt commodity spray attempts
state:up with missing challenge-ack. Cisco lists Snort coverage 66482-66483; Talos also references coverage for the wider campaign.Promote the fake peer to trusted state and land vmanage-admin access
Hello to move the peer into the UP state. Rapid7’s module then uses a VMANAGE_TO_PEER message to plant an attacker SSH key into vmanage-admin's authorized_keys, opening NETCONF over TCP 830 and persistent administrative access.- Successful pre-auth handshake abuse from step 2
- Target accepts peer transition to
UP
- Post-exploit actions are noisier than the bypass itself and may leave SSH/auth or control-connection artifacts
- Operators who compare system IPs, peer roles, and source IPs can catch bogus peers
/var/log/auth.log for Accepted publickey for vmanage-admin from unauthorized IPs and reviewing control-connection history for suspicious peers.Change fabric state and, in observed cases, try root escalation
- Administrative foothold on Controller/Manager
- Access to follow-on services such as NETCONF/SSH
- Root escalation is a second stage, not guaranteed by this CVE alone
- Well-instrumented admins can notice version downgrades, peer churn, or unexpected config writes
12346 to explicit, known SD-WAN peers only; if a controller or manager is reachable from the public internet or broad internal segments that do not need peering, close that path now.22 and 830 do not fix the bypass, but they reduce post-bypass usefulness by preventing easy follow-on access from arbitrary networks and force attackers to stay inside the control-plane path.request admin-tech, TAC review, auth.log checks for unexpected vmanage-admin public-key logins, and control-connection history validation for suspicious peers.state:up sessions with missing challenge-ack, unauthorized source IPs, and config changes through NETCONF.- MFA on the normal admin UI does not protect the vulnerable DTLS peering path; the bug bypasses trust before web authentication is relevant.
- A WAF is largely irrelevant because the exploit path is not HTTP; it is
vdaemonover DTLS/UDP12346. - Host-based allowlists that only watch interactive shell logins will miss the initial compromise, because the first stage is a fake control-plane peer, not a user login.
The supporting signals.
| In-the-wild status | Confirmed exploited. Cisco says it became aware of *limited exploitation* in May 2026, and Talos says active ITW exploitation is clustered as UAT-8616 with attempted SSH-key adds, NETCONF changes, and root escalation: Cisco advisory, Talos. |
|---|---|
| Public exploit / PoC | Weaponized module is public. Rapid7 published the Metasploit module auxiliary/admin/networking/cisco_sdwan_vhub_auth_bypass, which performs the DTLS/vHub bypass and SSH-key injection: module page, technical writeup. |
| EPSS | 0.77324 from your intel block, which is extremely high for defender triage. Translation: even before vendor context, the exploit-likelihood model already says this belongs near the top of the queue. |
| KEV status | KEV listed: yes. CISA added it to the Known Exploited Vulnerabilities catalog on 2026-05-14; multiple public summaries cite a federal due date of 2026-05-17: CISA KEV catalog, Tenable FAQ. |
| CVSS vector meaning | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H is the full no-auth remote compromise story. The only real-world qualifier missing from that math is exposure population: this is devastating when reachable, but not every enterprise exposes SD-WAN control components to the internet. |
| Affected footprint | Cisco says Controller and Manager are affected regardless of configuration across on-prem, Cloud-Pro, Cisco-managed cloud, and FedRAMP deployments. That is broad *within the product family*, even if the family itself is niche compared with mass-market edge software: Cisco advisory. |
| Fixed versions | Per Cisco, fixed releases are 20.9.9.1, 20.12.5.4, 20.12.6.2, 20.12.7.1, 20.15.4.4, 20.15.5.2, 20.18.2.2, 26.1.1.1, plus Cisco-managed cloud 20.15.506: Cisco advisory, remediation guide. |
| Scanning / exposure data | No authoritative public exposure count found in primary sources. What we do have is stronger: Cisco explicitly warns that controllers exposed to the internet and with ports exposed are at risk, and Rapid7 narrows the relevant surface to UDP 12346 plus follow-on SSH/NETCONF ports 22 and 830: Cisco advisory, Rapid7. |
| Disclosure timeline | Cisco first published the advisory on 2026-05-14 16:00 GMT. Rapid7 says Cisco confirmed the findings on 2026-03-20, and Talos/Tenable both place active exploitation at disclosure time: Cisco advisory, Rapid7. |
| Researcher / reporting org | Cisco credits Stephen Fewer and Jonah Burgess of Rapid7 for reporting the vulnerability. That matters because this is not vague bug-class speculation; there is a public technical root-cause analysis and operational exploit module behind it. |
Sources.
Why this verdict
- Started at Cisco's 10.0 because the vendor baseline fits the technical reality: unauthenticated remote compromise of the SD-WAN control plane with admin-level consequences.
- Reachability trims the score, not the bucket. The attacker needs UDP
12346to a Controller/Manager, which implies a narrower exposed population than mass-market edge bugs. That is real downward pressure, but it is population friction, not exploit friction. - KEV + Talos + Metasploit push it back up. This is not a lab-only edge case: there is active exploitation, a named threat cluster, Cisco IoC guidance, and a public weaponized module.
Why not higher?
I did not leave it at a perfect 10 because this is not universally reachable across a 10,000-host estate. Many organizations have only a few SD-WAN control components, and many of those are not broadly internet-exposed. That narrows the victim pool materially even though the technical impact is catastrophic once a target is reachable.
Why not lower?
A lower bucket would understate both the attacker position and the blast radius. This is PR:N/UI:N, already in KEV, and it targets a control-plane component where one successful hit can translate into fabric-wide configuration abuse and persistence.
Crowdsourced verification payload.
Run this on the target SD-WAN Controller/Manager shell or on an auditor workstation with the version string copied from show version. Example: bash cve-2026-20182-check.sh --version 20.12.6.1. It needs no elevated privileges when you pass --version; auto-detection may require access to run show version locally.
#!/usr/bin/env bash
# CVE-2026-20182 Cisco Catalyst SD-WAN version checker
# Usage:
# bash cve-2026-20182-check.sh --version 20.12.6.1
# bash cve-2026-20182-check.sh # best-effort auto-detect via 'show version'
# Exit codes:
# 0 = PATCHED
# 1 = VULNERABLE
# 2 = UNKNOWN
set -u
ver=""
if [[ $# -ge 2 && "$1" == "--version" ]]; then
ver="$2"
elif command -v show >/dev/null 2>&1; then
# Best-effort parse from local CLI output
ver=$(show version 2>/dev/null | grep -Eo '([0-9]+\.){1,4}[0-9]+' | head -n1 || true)
fi
if [[ -z "$ver" ]]; then
echo "UNKNOWN: unable to determine version; rerun with --version <x.y.z>"
exit 2
fi
# Compare dotted numeric versions.
vercmp() {
local IFS=.
local i
local -a a=($1) b=($2)
local len=${#a[@]}
if (( ${#b[@]} > len )); then len=${#b[@]}; fi
for ((i=0; i<len; i++)); do
local ai=${a[i]:-0}
local bi=${b[i]:-0}
((10#$ai > 10#$bi)) && return 1
((10#$ai < 10#$bi)) && return 2
done
return 0
}
lt() { vercmp "$1" "$2"; [[ $? -eq 2 ]]; }
ge() { vercmp "$1" "$2"; [[ $? -eq 0 || $? -eq 1 ]]; }
status="UNKNOWN"
reason="unrecognized release family"
# Cisco-managed cloud fixed release
if [[ "$ver" == "20.15.506" ]]; then
status="PATCHED"
reason="Cisco-managed cloud fixed release"
elif lt "$ver" "20.9"; then
status="VULNERABLE"
reason="earlier than 20.9 per Cisco advisory"
elif ge "$ver" "20.9" && lt "$ver" "20.10"; then
if lt "$ver" "20.9.9.1"; then
status="VULNERABLE"
reason="20.9 family fixed at 20.9.9.1"
else
status="PATCHED"
reason="20.9 family at or above 20.9.9.1"
fi
elif ge "$ver" "20.10" && lt "$ver" "20.12"; then
status="VULNERABLE"
reason="20.10/20.11 require migration to fixed 20.12.7.1 or later supported release"
elif ge "$ver" "20.12" && lt "$ver" "20.13"; then
if lt "$ver" "20.12.5.4"; then
status="VULNERABLE"
reason="20.12 up to 20.12.5.3 fixed at 20.12.5.4"
elif ge "$ver" "20.12.6" && lt "$ver" "20.12.6.2"; then
status="VULNERABLE"
reason="20.12.6.x fixed at 20.12.6.2"
elif ge "$ver" "20.12.7" && lt "$ver" "20.12.7.1"; then
status="VULNERABLE"
reason="20.12.7 fixed at 20.12.7.1"
else
status="PATCHED"
reason="20.12 family at or above a fixed maintenance release"
fi
elif ge "$ver" "20.13" && lt "$ver" "20.15"; then
status="VULNERABLE"
reason="20.13/20.14 require migration to fixed 20.15.5.2 or later supported release"
elif ge "$ver" "20.15" && lt "$ver" "20.16"; then
if lt "$ver" "20.15.4.4"; then
status="VULNERABLE"
reason="20.15 up to 20.15.4.3 fixed at 20.15.4.4"
elif ge "$ver" "20.15.5" && lt "$ver" "20.15.5.2"; then
status="VULNERABLE"
reason="20.15.5.x fixed at 20.15.5.2"
else
status="PATCHED"
reason="20.15 family at or above a fixed maintenance release"
fi
elif ge "$ver" "20.16" && lt "$ver" "20.18"; then
status="VULNERABLE"
reason="20.16/20.17 require migration to fixed 20.18.2.2 or later supported release"
elif ge "$ver" "20.18" && lt "$ver" "26.1"; then
if lt "$ver" "20.18.2.2"; then
status="VULNERABLE"
reason="20.18 family fixed at 20.18.2.2"
else
status="PATCHED"
reason="20.18 family at or above 20.18.2.2"
fi
elif ge "$ver" "26.1" && lt "$ver" "27.0"; then
if lt "$ver" "26.1.1.1"; then
status="VULNERABLE"
reason="26.1 family fixed at 26.1.1.1"
else
status="PATCHED"
reason="26.1 family at or above 26.1.1.1"
fi
fi
case "$status" in
VULNERABLE)
echo "VULNERABLE: $ver ($reason)"
exit 1
;;
PATCHED)
echo "PATCHED: $ver ($reason)"
exit 0
;;
*)
echo "UNKNOWN: $ver ($reason)"
exit 2
;;
esac