A maximum-severity authentication bypass in Cisco Catalyst SD-WAN Controller and Manager was disclosed by Cisco on February 27, 2026—but by that point, a sophisticated threat actor tracked as UAT-8616 had already been quietly operating inside target networks since at least 2023. Cisco Talos identified the exploitation campaign while investigating a live intrusion; the CVE didn’t exist in any advisory until Talos found it being weaponized.

Timeline

  • ~2023 — UAT-8616 begins exploiting CVE-2026-20127 against Cisco Catalyst SD-WAN deployments
  • Late 2025 — Cisco Talos detects active intrusion activity during an incident response engagement and identifies a novel auth bypass
  • February 27, 2026 — Cisco publishes advisory cisco-sa-sdwan-rpa-EHchtZk, disclosing CVE-2026-20127 (CVSS 10.0) with confirmed in-the-wild exploitation
  • Late March 2026 — Security researchers confirm widespread opportunistic scanning and exploitation beyond UAT-8616 targeting

What’s Vulnerable

CVE-2026-20127 affects two Cisco Catalyst SD-WAN components:

  • Cisco Catalyst SD-WAN Controller (formerly SD-WAN vSmart)
  • Cisco Catalyst SD-WAN Manager (formerly SD-WAN vManage)

An unauthenticated remote attacker can send a specially crafted request that bypasses the authentication layer entirely, logging in as a high-privileged internal user account. No credentials, no MFA bypass required — just network access to the management interface.

The Post-Exploitation Chain

The initial foothold is high-privileged but not root. UAT-8616 solved that with a technique worth understanding in detail: they deliberately downgraded the compromised controller to a build known to be vulnerable to CVE-2022-20775, a local privilege escalation disclosed in 2022. After exploiting CVE-2022-20775 to obtain root on the downgraded image, they restored the controller to its original software version. The result: root-level persistence on a controller that appears to be running its normal, expected software version.

This isn’t just clever—it’s forensically hostile. A defender checking software versions post-incident would see nothing unusual. The downgrade and re-upgrade activity would appear in upgrade logs, but without the context of what happened between those events, it reads as administrative noise.

With root on the SD-WAN Controller, UAT-8616 joined rogue peers to the organization’s SD-WAN control plane and management plane. A Controller peer in an SD-WAN fabric can distribute routing policy, NAT policy, and application-aware routing configurations across the entire WAN fabric—affecting every branch, data center, and cloud uplink governed by that controller.

Why This Matters

SD-WAN controllers are among the highest-trust components in enterprise network architecture. They’re the policy engine for the entire WAN fabric. An attacker with root on a Controller can silently reroute traffic, insert interception points, or manipulate which paths specific application flows traverse—changes that are difficult to detect from the data plane alone.

The three-year exploitation window is the headline, but the real takeaway is that a CVSS 10.0 vulnerability existed in a widely deployed network management product for years without triggering detection. This was not lateral movement from another compromised host; it was direct unauthenticated access to the network control plane.

What to Do

  • Patch immediately. Apply the fixes in cisco-sa-sdwan-rpa-EHchtZk. If you can’t patch, restrict management-plane access to known administrative source IPs via ACLs as an interim measure.
  • Audit control connection peering events. Talos identifies these as the primary forensic indicator. Any control connection peering event in vManage or Controller logs that you can’t attribute to a known administrative action warrants immediate investigation. Look for unexpected vmanage peering types in particular.
  • Review software upgrade history. Look for unexpected downgrade/upgrade sequences on your SD-WAN Controllers going back to 2023. A downgrade followed by a re-upgrade within a short window (hours to days) on a production controller is suspicious.
  • Check for rogue SD-WAN peers. Enumerate all registered peers in your SD-WAN fabric and validate each one against your asset inventory. An unknown edge device or controller peer is a potential implant.
  • Rotate SD-WAN management credentials. If you can’t rule out exposure, treat all management-plane credentials as compromised and rotate them before repatching.
  • Verify policy integrity. Review current SD-WAN routing and application policies against a known-good baseline. A sophisticated actor with control-plane access would modify policies to achieve persistent traffic manipulation rather than obvious changes.

Patched versions are listed in the Cisco advisory; check your specific SD-WAN software train against the fixed release table.