CVE-2026-20127: Cisco Catalyst SD-WAN Authentication Bypass

Three years of silent access, one busted peering handshake, and a control plane that belonged to someone else

CVE-2026-20127: Cisco Catalyst SD-WAN Authentication Bypass

CVE-2026-20127: Cisco Catalyst SD-WAN Authentication Bypass

Three years of silent access, one busted peering handshake, and a control plane that belonged to someone else

The Vulnerability

CVE-2026-20127 is a CVSS 10.0 authentication bypass vulnerability in the peering authentication mechanism of Cisco Catalyst SD-WAN Controller (formerly vSmart) and Cisco Catalyst SD-WAN Manager (formerly vManage). The flaw is classified under CWE-287 (Improper Authentication) and allows an unauthenticated, remote attacker to bypass the peering authentication process entirely and obtain administrative privileges on an affected system.

A perfect ten. No credentials needed. No user interaction required. Attack complexity: low. And critically, the scope is marked as “Changed,” meaning a successful exploit doesn’t just compromise the controller itself, it gives an attacker leverage over the entire SD-WAN fabric those controllers manage.

To understand why this is so bad, you have to understand what a Catalyst SD-WAN Controller actually does. The Controller is the brain of the SD-WAN overlay. It uses the Overlay Management Protocol (OMP) to distribute routing intelligence, push security policy, manage WAN path selection, and distribute encryption keys to every edge device in the fabric. When you own the Controller, you own the network map. You control what talks to what, how traffic is routed, and what policies are enforced.

The bug sits in how the SD-WAN control components validate inbound peering connections. When a new peer attempts to establish a control connection, there is an authentication handshake that is supposed to occur. In vulnerable versions, that handshake is broken. A crafted request bypasses the expected validation and results in the attacker being logged in as a high-privileged internal user account (non-root, but we will get to the root escalation in a moment). From there, the attacker lands directly on NETCONF, the protocol used to push configuration changes across the fabric.

NETCONF access on a Catalyst SD-WAN Controller is the skeleton key. Every edge device in the deployment trusts the controller. With that trust relationship in hand, an attacker can manipulate routing tables, modify policies, redirect traffic, and establish persistence across the entire WAN.

Timeline and Active Exploitation

Here is where this gets uncomfortable for everyone who thought their SD-WAN was quietly doing its job.

Cisco published the advisory on February 25, 2026, in coordination with the Australian Signals Directorate’s Australian Cyber Security Centre (ASD’s ACSC), who was credited with reporting the vulnerability. The same day, Cisco Talos published a blog attributing active exploitation to a cluster they track as UAT-8616, assessed with high confidence as a highly sophisticated threat actor.

The part that should make you pause: Talos telemetry shows exploitation activity going back at least three years, to 2023. This was not a vulnerability discovered and immediately weaponized. This was a vulnerability that was apparently discovered, weaponized, and kept quiet for years while the actor worked through targets at their leisure. When exploitation dates back to 2023 and public discovery happens in late 2025, that multi-year gap describes controlled, deliberate operations, not opportunistic scanning.

Key dates in the disclosure chain:

The coordinated multi-agency disclosure, the Emergency Directive, the Five Eyes involvement, and the CISA characterization of this as posing “imminent risk to federal networks” tells you everything about how this was assessed behind closed doors.

No public proof-of-concept existed as of initial disclosure. That buys defenders a window, but it is a shrinking one.

Affected Versions and Patch Status

The vulnerability affects Cisco Catalyst SD-WAN Controller and Cisco Catalyst SD-WAN Manager across all deployment types: on-premises, Cisco Hosted SD-WAN Cloud, Cisco Hosted SD-WAN Cloud - Cisco Managed, and the FedRAMP environment. It is not configuration-dependent. If you are running a vulnerable version, you are vulnerable.

Cisco Catalyst SD-WAN Release Fixed Version
Earlier than 20.9 Migrate to a supported release
20.9 20.9.8.2 (estimated February 27, 2026)
20.11 (EoSM) 20.12.6.1
20.12.5 20.12.5.3
20.12.6 20.12.6.1
20.13 (EoSM) 20.15.4.2
20.14 (EoSM) 20.15.4.2
20.15 20.15.4.2
20.16 (EoSM) 20.18.2.1
20.18 20.18.2.1

Releases marked EoSM (End of Software Maintenance) have fixed versions available but Cisco strongly encourages migration to a currently supported release. Releases earlier than 20.9 require migration entirely. There is no patch for end-of-life versions, and the advisory is explicit: there are no workarounds that fully address the vulnerability.

One thing worth calling out: the Cisco Hosted SD-WAN Cloud and FedRAMP-managed deployments listed as “guardrails are in place” in the advisory’s mitigation table. That is good for managed customers, but on-premises deployments and self-managed cloud deployments are entirely on the customer to address.

Proof of Concept Details

As of initial disclosure on February 25, 2026, no public proof-of-concept had been published. Cisco’s Snort rules 65938 and 65958 were released alongside the advisory, providing detection coverage for known exploitation patterns. Tenable noted at time of writing that if a PoC drops, expect a rapid shift from targeted exploitation by sophisticated actors to mass scanning and spray-and-pray exploitation.

That is the arc every publicly disclosed auth bypass follows. Right now the exploitation is deliberate and targeted. When a PoC lands, the noise floor rises significantly and defenders lose the relative luxury of distinguishing targeted compromise from opportunistic scanning.

The conceptual exploitation flow looks like this:

# Simplified representation of the vulnerability
def sdwan_peering_handshake(peer_connection):
    # Intended flow: validate peer identity before granting access
    peer_identity = extract_peer_identity(peer_connection)
    
    # Bug: validation mechanism is not functioning correctly
    # Crafted requests can bypass this check
    if validate_peer_auth(peer_identity):  # <- broken, can be bypassed
        grant_access(peer_connection, privilege_level="high")
        return open_netconf_session(peer_connection)
    else:
        reject_connection(peer_connection)

The attacker’s goal at this stage is simple: land as the internal high-privileged user and get a NETCONF session open. Everything else follows from that.

Technical Exploitation Analysis

To understand the vulnerability, you need to understand how Cisco Catalyst SD-WAN establishes and maintains its control plane.

The SD-WAN Control Plane Architecture

The Catalyst SD-WAN fabric relies on several components working together:

Controllers and Managers form peer relationships with each other and with edge devices. These peering relationships are how the control plane stays synchronized. The OMP runs over DTLS or TLS tunnels established after a successful peer authentication handshake.

The Peering Authentication Mechanism

When a new peer connection is initiated, the connecting component is expected to prove its identity before being allowed to establish an OMP or NETCONF session. This normally involves certificate-based mutual authentication. The vulnerability is that this validation mechanism is not functioning correctly on affected versions.

The precise technical root cause has not been publicly detailed by Cisco beyond “the peering authentication mechanism in an affected system is not working properly.” What Talos and government partners have confirmed through incident response is the observable outcome: crafted requests bypassing the handshake and resulting in authenticated access as the internal vmanage-admin equivalent user.

Once that bypass lands, the attacker is in as a high-privileged non-root account. The immediate value here is NETCONF access.

NETCONF as the Exploitation Target

NETCONF (Network Configuration Protocol) over SSH is the primary programmatic interface for pushing configuration to Catalyst SD-WAN devices. It runs on port 830. With an authenticated NETCONF session on the Manager or Controller, an attacker can:

A quick illustration of what NETCONF interaction looks like from an attacker’s perspective once access is obtained:

<!-- Example NETCONF RPC to query running configuration -->
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <get-config>
    <source>
      <running/>
    </source>
  </get-config>
</rpc>

<!-- Response includes full fabric configuration, device inventory,
     routing policies, credentials, and topology data -->

That is the entire network’s configuration delivered in response to a single authenticated request. From a post-exploitation standpoint, this is extraordinary reach.

UAT-8616’s Observed Exploitation Chain

Talos and intelligence partners documented the actual exploitation chain as observed in the wild. This is more interesting than just the auth bypass itself.

Stage 1: Initial Access via CVE-2026-20127

The actor sends crafted requests to an internet-exposed SD-WAN Controller or Manager, bypasses the peering authentication, and obtains the high-privileged non-root account session. The first observable artifact here is an unauthorized control connection peering event in the VDAEMON logs, appearing as a new vmanage peer type coming from an unexpected IP:

Feb 20 22:03:33 vSmart-01 VDAEMON_0[2571]: %Viptela-vSmart-VDAEMON_0-5-NTCE-1000001:
control-connection-state-change new-state:up peer-type:vmanage
peer-system-ip:1.1.1.10 public-ip:192.168.3.20 public-port:12345
domain-id:1 site-id:1005

Stage 2: Rogue Peer Addition

With administrative access, the actor adds a malicious rogue peer to the SD-WAN fabric configuration. This establishes a persistent, attacker-controlled node within the control plane. The rogue peer looks like a legitimate part of the network to the Controller’s perspective.

Stage 3: Root Escalation via Software Version Downgrade

This is the clever part, and it is worth dwelling on because it shows how well UAT-8616 understood this platform.

The non-root high-privileged account obtained through CVE-2026-20127 is powerful but not root. To get there, the actor reaches back to a pair of older Cisco SD-WAN vulnerabilities that were patched years ago but remain exploitable on older software versions: CVE-2022-20775 and CVE-2022-20776.

CVE-2022-20775 is a path traversal vulnerability in the web-based management interface of Cisco SD-WAN. An authenticated attacker can read arbitrary files on the underlying operating system by sending crafted HTTP requests, with path traversal strings embedded in the username field or request parameters. CVE-2022-20776 is a companion privilege escalation vulnerability in the same interface that allows an authenticated attacker to escalate to root by sending specially crafted HTTP requests. Both were patched in 2022 but fixed releases are irrelevant to an attacker who can choose which version is running.

The technique works like this: using the administrative access obtained through CVE-2026-20127, the actor downgrades the SD-WAN software to a version where CVE-2022-20775 and CVE-2022-20776 are still present and exploitable. The actor then uses those vulnerabilities to escalate to root. Once root is achieved, the actor upgrades the device back to the original software version, erasing the version that made the escalation possible.

The device ends up back on the version it started on. From a version check perspective, nothing looks wrong.

Talos’ language on this technique is worth quoting accurately: Talos and intelligence partners assessed that the actor “likely” escalated to root via the version downgrade path, based on intelligence partner findings rather than direct Talos forensic reconstruction. That qualifier matters for formal incident assessments. The technique is consistent with all observed artifacts and is the most operationally coherent explanation, but organizations should note that it is an intelligence-derived assessment rather than a confirmed forensic chain.

On February 25, 2026, CISA added both CVE-2022-20775 and CVE-2022-20776 to the Known Exploited Vulnerabilities catalog alongside CVE-2026-20127. The simultaneous KEV addition of both older vulnerabilities is a strong signal that active exploitation of the chained technique was confirmed across multiple victim investigations, not just theorized.

The version downgrade and subsequent revert is detectable if you know what to look for. The logs will show an unexpected version transition with associated reboot:

Waiting for upgrade confirmation from user. Device will revert to
previous software version <version> in '100' seconds unless confirmed.
Software upgrade not confirmed. Reverting to previous software version

An unexpected version downgrade/upgrade sequence accompanied by a system reboot, with no corresponding change management ticket, is a significant indicator of compromise. The critical forensic detail here is timing: the window between the downgrade and the reupgrade may be short. If log forwarding to an external SIEM was not capturing that window, the only remaining evidence is the transition events themselves, not the exploitation activity that occurred between them.

Stage 4: Persistence

With root access, the actor establishes long-term persistence. Observed mechanisms include unauthorized SSH keys added to the vmanage-admin or root accounts, unauthorized user account creation (with subsequent deletion to reduce artifacts), and sshd configuration changes enabling PermitRootLogin.

The delete-after-create pattern for user accounts is worth calling out specifically because it is a noise reduction technique. The account gets created to do work, then deleted to reduce the forensic footprint. The creation event may exist in logs. The deletion event may exist in logs. What the account actually did between creation and deletion may not.

Stage 5: Long-Term Fabric Access

With persistent root-level access to the Controller and rogue peer relationships established, the actor maintains ongoing visibility into and control over the SD-WAN fabric. Routing manipulation, traffic inspection, lateral movement into connected network segments, and reconnaissance of connected infrastructure all become possible from this position.

Talos assessed UAT-8616 with high confidence as targeting critical infrastructure sectors specifically. The patient, multi-year operational timeline is consistent with a nation-state backed actor conducting long-term strategic access operations rather than financially motivated intrusion.

Considerations and Limitations: Forensics in Practice

This is the section where we talk about what actually helps you and what sounds good on a slide but falls apart in a real investigation.

What the Attacker Does NOT Leave Behind

The exploitation itself, the peering authentication bypass, generates a control connection event in the VDAEMON logs. It does NOT generate a traditional failed authentication event because the attacker is not failing, they are succeeding through a broken validation path. There is no “authentication failure” log to alert on. There is just a new peer connection from an unexpected IP address, which looks structurally similar to a legitimate peer event.

The version downgrade technique used for root escalation is particularly forensically hostile. The actor downgrades, exploits CVE-2022-20775 to get root, then upgrades back. If log retention is short, the window of the downgrade may not be captured. If SIEM forwarding is not configured, those logs may only exist locally and are vulnerable to manipulation by an attacker who now has root access.

SSH authorized_keys modification at the root level is a favorite persistence mechanism precisely because it is often not monitored. An extra public key in /root/.ssh/authorized_keys or /home/vmanage-admin/.ssh/authorized_keys gives indefinite access with no further vulnerability required. It looks like nothing in passive monitoring.

What We Have Seen in the Wild

Per Talos and the government advisories, the following artifacts have been observed in compromised environments:

The log truncation is the one that really stings. If an attacker has achieved root and has cleared or truncated logs locally, and you do not have logs forwarded to an external SIEM, your forensic investigation starts at a significant disadvantage. You may be able to detect the act of truncation (size 0 or near-zero log files that should be populated), but reconstructing what happened before the truncation requires external log sources.

The Three-Year Problem

Talos telemetry shows exploitation going back to 2023. For organizations that may have been compromised during that window, the forensic situation is stark. Most organizations retain logs for 30-90 days, sometimes less. If compromise occurred in 2023 or 2024, those log entries are gone. You can confirm current indicators of compromise but you cannot reconstruct the historical access timeline.

This means that for organizations with internet-exposed Catalyst SD-WAN infrastructure, the correct assumption is: if you were running vulnerable versions over the last three years, treat the investigation as a potential long-term compromise case, not just a vulnerability remediation exercise.

Scope Assessment is Hard

NETCONF access to the Controller means the attacker had the ability to manipulate the entire fabric. Determining what they actually did with that access requires detailed NETCONF session logs, which many deployments do not maintain at the required verbosity. Without those logs, you can establish that access occurred but you cannot enumerate all configuration changes, all topology queries, or all traffic that may have been redirected or inspected.

Detection and Hunting

The primary detection surface is the Catalyst SD-WAN control plane logs. Here is what to look for.

Core Hunting Focus: Peering Events

Every control connection peering event needs to be validated. The key log source is the VDAEMON log on SD-WAN Controllers and Managers. Look for control-connection-state-change events with new-state:up and validate:

# Example suspicious peering event - validate all fields
Jul 26 22:03:33 vSmart-01 VDAEMON_0[2571]:
%Viptela-vSmart-VDAEMON_0-5-NTCE-1000001:
control-connection-state-change new-state:up
peer-type:vmanage
peer-system-ip:1.1.1.10          # <- Is this in your asset inventory?
public-ip:192.168.3.20           # <- Is this a known controller IP?
public-port:12345
domain-id:1
site-id:1005

SSH Authentication Log Review

Audit /var/log/auth.log for Accepted publickey for vmanage-admin entries. Cross-reference every source IP against your documented controller inventory. Any IP not in that inventory that successfully authenticated should be treated as a compromise indicator.

# Indicator: Successful pubkey auth from unknown IP
2026-02-10T22:51:36+00:00 vm sshd[804]:
Accepted publickey for vmanage-admin from <UNKNOWN_IP>
port [PORT] ssh2: RSA SHA256:[KEY_FINGERPRINT]

Collect all SSH key fingerprints from these log entries and compare against authorized keys. Any fingerprint not in your authorized inventory is an attacker-controlled key.

SSH authorized_keys Integrity Check

Check these locations manually:

# Check for unauthorized SSH keys
cat /home/vmanage-admin/.ssh/authorized_keys
cat /root/.ssh/authorized_keys

# Check sshd configuration for PermitRootLogin changes
grep PermitRootLogin /etc/ssh/sshd_config

# Check for recently modified authorized_keys files
find /home /root -name "authorized_keys" -newer /etc/passwd -ls

Any key not documented in your organization’s key management process is suspect.

Log Integrity Checks

# Check for truncated or suspiciously small log files
ls -lh /var/log/sdwan/
ls -lh /var/log/

# A size-0 or near-zero log that should have content is a red flag
# Check for cleared bash history alongside present cli-history
ls -la /home/vmanage-admin/.bash_history
ls -la /home/vmanage-admin/.cli-history

# Review for version downgrade/upgrade events
grep -i "upgrade" /var/log/sdwan/*.log | grep -i "revert\|downgrade\|previous"

CVE-2022-20775 and CVE-2022-20776 Path Traversal Indicators

If the actor used the downgrade + path traversal technique, the primary forensic artifact is path traversal strings in the vdebug logs and authentication logs. CISA specifically identified the following log files as the correct hunting targets for CVE-2022-20775 exploitation evidence:

# Hunt for path traversal strings across SD-WAN logs and vdebug specifically
grep -r "\.\./\.\." /var/volatile/log/vdebug /var/log/tmplog/vdebug /var/log/sdwan/
grep -r "/\\\n&\.\." /var/volatile/log/vdebug /var/log/tmplog/vdebug /var/log/sdwan/
grep -r "%2e%2e" /var/volatile/log/vdebug /var/log/tmplog/vdebug /var/log/sdwan/

# Also check sw_script_synccdb.log for related artifacts
grep -i "traversal\|\.\./\|%2e%2e" /var/volatile/log/sw_script_synccdb.log

# Look for version downgrade/upgrade events bracketing the exploitation window
grep -i "upgrade\|downgrade\|revert\|previous.*version" /var/log/sdwan/*.log

The path traversal strings showing up in the username field of authentication events or in the vdebug output are a direct artifact of CVE-2022-20775 being executed. If you find those strings, the escalation chain was attempted regardless of whether the subsequent reupgrade erased the vulnerable version from the current running state.

NETCONF Session Auditing

If you have NETCONF session logging configured (verbosity-dependent), review for sessions that were not initiated by known management systems or authorized operators:

# NETCONF runs on port 830
# Check for connections from unexpected sources
grep -i "netconf\|port.*830\|830.*netconf" /var/log/sdwan/*.log

Snort Detection Rules

Cisco released Snort rules SID 65938 and SID 65958 alongside the advisory, covering the initial authentication bypass and post-exploitation NETCONF command execution respectively. Both are available via the Snort subscriber ruleset and should be verified as active in any Snort or Cisco FTD/FMC deployment protecting SD-WAN infrastructure.

When you suspect compromise, time is your enemy. Logs rotate, disk state changes, and an attacker with root access may have set up cleanup mechanisms. Collect in this order:

  1. Take a virtual snapshot or disk image of all SD-WAN control components before making any changes
  2. Collect all available VDAEMON logs, auth logs, and system logs from the device and from any external SIEM or syslog server
  3. Collect the current authorized_keys for all relevant accounts
  4. Collect the current sshd configuration
  5. Collect any available NETCONF session logs
  6. Run request admin-tech on each control component and provide the resulting file to Cisco TAC for review

If you are opening a Cisco TAC case, which Cisco explicitly recommends for suspected compromise, the admin-tech output is the first thing they will ask for.

Remediation and Mitigations

Patch First

There are no workarounds that fully remediate CVE-2026-20127. The only complete fix is upgrading to a fixed release. Refer to the table in the Affected Versions section above.

For the 20.9 release, the fixed version (20.9.8.2) was estimated for release on February 27, 2026. Monitor Cisco’s advisory for confirmation.

For organizations on End-of-Software-Maintenance releases (20.11, 20.13, 20.14, 20.16), fixed versions exist but migration to a currently supported release is strongly recommended.

Temporary Network Mitigations (On-Prem Deployments)

While preparing for patching, the most impactful mitigation is access control. Ports 22 (SSH) and 830 (NETCONF) on SD-WAN Controllers and Managers should be restricted by ACL, security group rule, or firewall rule to permit only known, documented controller IPs and authorized management infrastructure. If you cannot explain why a given IP should be able to reach port 830 on your Controller, it should not be allowed to.

# Conceptual ACL approach for on-prem deployments
# Restrict ports 22 and 830 to known controller system IPs and
# authorized management network ranges ONLY

permit tcp <controller_ip_1/32> any eq 22
permit tcp <controller_ip_2/32> any eq 22
permit tcp <mgmt_network/cidr> any eq 22
permit tcp <controller_ip_1/32> any eq 830
permit tcp <controller_ip_2/32> any eq 830
deny tcp any any eq 22
deny tcp any any eq 830

SD-WAN Hardening Guidance

Beyond the immediate patch, Cisco’s SD-WAN Hardening Guide outlines the configuration baseline that should have been in place before this. Key areas:

Credential Rotation

If compromise cannot be ruled out, rotate all relevant credentials:

Closing Assessment

CVE-2026-20127 is a textbook critical network infrastructure vulnerability: zero credentials required, remote exploitation, immediate access to a privileged interface with fabric-wide reach, and evidence of exploitation by a patient, sophisticated actor who sat on it for years before anyone noticed.

The three-year exploitation window is what defines the actual organizational risk here. Patching addresses future exposure. It does not address the question of whether your Controllers were quietly owned since 2023 and whether a rogue peer is still sitting in your fabric waiting to be re-activated.

For defenders, a few realities to sit with.

First, if your SD-WAN management interfaces were reachable from the internet, and you were running vulnerable versions, the forensic question is not “were we targeted” but “what was done with that access.” Those are different investigations with different scopes.

Second, log forwarding to an external SIEM is not optional for infrastructure at this risk tier. The fact that an attacker with root access can truncate local logs means that local logs cannot be your only forensic source. If you are only logging locally on SD-WAN control components, your post-incident investigation capability is severely limited.

Third, the combination of CVE-2026-20127 and CVE-2022-20775 as a chained privilege escalation path tells you something about how thoroughly this actor understood the target platform. The downgrade-exploit-reupgrade technique is operational tradecraft developed through experimentation and refinement, not something you produce on day one. Multi-year timelines produce refined attack chains.

Patch the CVE. Validate your peering events. Audit your authorized_keys. Forward your logs. And if you are running a critical SD-WAN deployment with internet-exposed control components, assume the worst and investigate accordingly.

References