Declare Yourself Trusted: Inside UAT-8616's Three-Year Run Against Cisco Catalyst SD-WAN

For at least three years, a threat actor Cisco Talos calls UAT-8616 has had a working answer to the question every SD-WAN controller has to ask a device that shows up asking to peer: who are you? The answer it found was: whatever you want to be. No certificate needed.

That’s not editorializing. It’s the literal mechanism behind CVE-2026-20182, one of two maximum-severity (CVSSv3 10.0) authentication bypasses in Cisco Catalyst SD-WAN Controller and Catalyst SD-WAN Manager that UAT-8616 has been chaining since 2023, and that Cisco, Talos, CISA, and the Five Eyes nations spent most of 2026 responding to in public.

The peering handshake, and where it broke

Part 1 of the Cisco Catalyst SD-WAN Deep Dive series covers this in full, but the short version: a WAN Edge doesn’t just show up and start forwarding traffic. It authenticates to the control plane first, over DTLS, and that authentication is supposed to be certificate-based. Controllers and edges hold certificates issued through the fabric’s own PKI, and the handshake that brings a control connection up is where a device proves it is what it claims to be before vSmart or vManage treats it as a trusted peer.

CVE-2026-20182 lives in that handshake, specifically in the vdaemon service listening on UDP/12346. An unauthenticated remote attacker can declare an arbitrary device type during the handshake and skip certificate validation entirely, emerging on the other side as a trusted peer of the controller or manager. From there, Cisco documented attackers using that trusted-peer status to inject an attacker-controlled public key directly into the vmanage-admin account’s authorized_keys file. No password guessed, no session hijacked. The control plane just accepted the claim.

CVE-2026-20127, patched three months earlier in February 2026, is a related but distinct flaw in the same peering authentication mechanism. It lets an unauthenticated attacker log in as an internal, high-privileged, non-root account and reach NETCONF on TCP/830, the same interface vManage itself uses to enumerate, modify, and push templates and policy across the fabric. Talos’s own hunt guidance says UAT-8616 has been exploiting this one since at least 2023, chaining it with CVE-2022-20775, a four-year-old local privilege escalation bug, to go from that internal account to root.

Two different bugs, two different entry points, one shared failure mode: the barrier between an unauthenticated stranger and a trusted fabric member turned out to have exactly one implementation, and no fallback when that implementation had a hole in it.

What a trusted peer can do

This is the part that makes the vulnerability worse than a typical remote code execution bug, not better. vManage and vSmart aren’t ordinary hosts. They’re the management and control planes for the entire overlay. Once UAT-8616 held either an SSH key on vmanage-admin or NETCONF access, Cisco’s own incident notes describe a fairly consistent playbook: create a hidden local account, push or alter templates and policy through the exact same NETCONF path vManage’s own UI uses, and clear the bash_history and CLI history on the accounts doing it. Talos flags the absence of that history, on an account that was clearly used interactively, as one of the highest-fidelity indicators of compromise available to defenders.

Talos assesses UAT-8616 as a highly sophisticated actor with infrastructure overlapping known Operational Relay Box networks, targeting critical infrastructure sectors specifically. That’s consistent with the target profile: SD-WAN controllers are usually reachable from the internet by design, because edges at branch sites need to phone home from wherever they’re deployed. The convergence of ZTNA and SD-WAN post on this site made a version of this argument from the data-plane side: identity-based trust has to replace network-position trust as the SD-WAN edge takes on more of the security stack. UAT-8616 is the control-plane version of the same lesson. An internet-facing management plane is only as safe as its authentication, and here, authentication had a shortcut.

The response, and what to actually check

CISA added CVE-2026-20182 to its Known Exploited Vulnerabilities catalog on May 14, 2026, the same day it issued Emergency Directive 26-03 with a remediation deadline of May 17, alongside published hunt and hardening guidance. The Five Eyes nations coordinated on the response. Cisco’s fixed releases span the supported train: 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, and 26.1.1.1, with no workaround available for anyone still running an affected version. If you administer a Catalyst SD-WAN fabric and haven’t checked your controller and manager versions against that list since May, that’s the first thing to do, not the last.

Beyond patching, the indicators worth hunting for specifically: local accounts created and later deleted with no corresponding bash_history or cli-history, SSH keys in vmanage-admin’s authorized_keys that nobody on the team put there, interactive root sessions with unfamiliar known_hosts entries, and NETCONF-driven template or policy changes that don’t line up with a change record. None of that requires exotic tooling. It requires actually looking, on a system a lot of teams treat as infrastructure they configure once and then leave alone.

The pattern, not just the CVE

Neither of these bugs is exotic engineering. They’re both, in different ways, a control plane trusting a claim it should have verified. The three-planes framing this site keeps coming back to exists because every SD-WAN vendor argument, every architecture decision, and apparently every serious vulnerability in the category traces back to which plane is doing what, and what happens when one of them gets too trusting about who it’s talking to. UAT-8616 didn’t need a zero-click exploit chain or a supply-chain compromise. It needed a controller that would take “I’m a WAN Edge” at face value.