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
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. |
noisgate verdict.
The decisive factor is confirmed active exploitation of a pre-auth remote control-plane bypass on a system that can steer the whole SD-WAN fabric. I am trimming it below a perfect 10 only because reachability to Controller/Manager peering services is materially narrower than a generic internet web stack, but once reachable the exploit chain is short and the blast radius is enormous.
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.
What to do — in priority order.
- Block untrusted access to UDP 12346 immediately — Treat this as the main kill switch and deploy within hours because exploitation is active. Restrict DTLS peering on UDP
12346to 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. - Constrain SSH and NETCONF to management sources only — Deploy within hours. Tight ACLs on TCP
22and830do 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. - Pull admin-tech and review Cisco IoCs — Do this within hours before major cleanup so you preserve evidence. Cisco explicitly prioritizes
request admin-tech, TAC review,auth.logchecks for unexpectedvmanage-adminpublic-key logins, and control-connection history validation for suspicious peers. - Update Talos/Snort coverage and monitor peer anomalies — Deploy within hours. Ensure sensors that can see SD-WAN control traffic have current Talos content, and alert on unexpected peer roles,
state:upsessions with missingchallenge-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.
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
If you remember one thing.
admin-tech, block untrusted reachability to UDP 12346 and tightly restrict 22/830, then move affected systems to a fixed release the same day if operationally possible. From a policy standpoint, your noisgate mitigation SLA here is effectively immediate due to exploitation evidence, and your noisgate remediation SLA should not be allowed to drift beyond the normal <= 90 days critical window even for lower-exposure internal controllers.Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.