Cisco corrige un bypass de autenticación crítico en Catalyst SD-WAN

Cisco ha publicado parches para CVE-2026-20182, un fallo crítico en Catalyst SD-WAN que permite a un atacante remoto sin autenticar lograr acceso con privilegios administrativos y manipular la configuración del tejido. La explotación se ha observado de forma limitada y no existen soluciones alternativas, por lo que la respuesta pasa por actualizar, reducir exposición y revisar posibles señales de compromiso.

La seguridad del plano de control en entornos SD-WAN vuelve a situarse en el centro de atención por un defecto que afecta a componentes que suelen estar muy cerca del ‘corazón’ de la red. En despliegues donde Cisco Catalyst SD-WAN Controller y Cisco Catalyst SD-WAN Manager concentran la orquestación y las conexiones de control, un fallo crítico puede traducirse en cambios de configuración a gran escala, pérdida de integridad del enrutamiento y acceso persistente a funciones de administración.

La vulnerabilidad CVE-2026-20182 tiene severidad crítica (CVSS 10.0) y permite a un atacante remoto sin autenticar eludir la autenticación y obtener privilegios administrativos en los componentes de control afectados. El problema reside en el mecanismo de autenticación durante el emparejamiento al establecer conexiones de control, de forma que un actor externo puede ‘presentarse’ como un peer válido y alcanzar un nivel de acceso equivalente al de un usuario interno de alto privilegio, aunque no se trate de acceso root. Aun así, el impacto es especialmente delicado porque habilita el acceso a NETCONF y, con ello, la capacidad de manipular la configuración del tejido SD-WAN.

El riesgo se dispara cuando los sistemas de Catalyst SD-WAN Controller están expuestos a Internet con puertos accesibles públicamente. La superficie de ataque descrita incluye vdaemon sobre DTLS en UDP 12346, además de NETCONF over SSH en TCP 830 y SSH en TCP 22. En la práctica, comprometer vdaemon puede implicar comprometer la confianza del tejido, ya que el atacante puede establecer relaciones de peering que no deberían existir y, después, aprovechar interfaces de gestión para mantener control.

A nivel técnico, el bypass puede lograrse completando el DTLS handshake con cualquier certificado y respondiendo al CHALLENGE con un CHALLENGE_ACK que declara un tipo de dispositivo vHub con el valor indicado, evitando así parte de la verificación del certificado en el flujo de vdaemon. Tras ello, el envío de un mensaje Hello permite que el peer pase a estado up una vez marcado como autenticado. Además, se ha descrito una vía de persistencia basada en la inyección de una clave SSH mediante MSG_VMANAGE_TO_PEER, un tipo de mensaje que permite escribir en modo append en /home/vmanage-admin/.ssh/authorized_keys, facilitando accesos posteriores. Existe incluso un módulo de Metasploit, cisco_sdwan_vhub_auth_bypass, que automatiza el bypass y la inyección de claves, y abre la puerta a interactuar con NETCONF por SSH en el puerto 830.

Se ha observado explotación de forma limitada en mayo de 2026, y no hay mitigaciones parciales que ‘compensen’ el defecto. La corrección requiere actualizar a versiones específicas según rama, con ejemplos como 20.9.9.1, 20.12.7.1, 20.12.6.2, 20.12.5.4, 20.15.5.2, 20.15.4.4, 20.18.2.2 o 26.1.1.1. En entornos Cisco SD-WAN Cloud gestionados, la corrección se incorpora en 20.15.506 sin acción del cliente, pero en despliegues on premises la actualización es imprescindible. En paralelo, conviene recordar que se ha señalado CVE-2026-20127 como vulnerabilidad distinta, ya corregida previamente, y que en el ecosistema SD-WAN se han descrito cadenas de ataque con otros CVE, lo que refuerza la necesidad de parchear de forma integral, no solo ‘el último’ fallo.

Antes de aplicar cambios, se recomienda conservar evidencias ejecutando request admin-tech en cada componente de control. Para búsqueda de compromisos, un primer punto de control es /var/log/auth.log, identificando entradas como Accepted publickey for vmanage-admin desde IPs no autorizadas. También es útil comparar las IPs observadas con los System IP configurados en la WebUI en la ruta de dispositivos, para detectar incoherencias. En los controladores, los eventos de peering deben validarse manualmente, revisando hora, IP pública de origen, system IP, tipo de peer y su correlación con actividad autorizada, especialmente si aparecen peers de tipo vmanage fuera de lo esperado.

Como apoyo adicional, puede revisarse el estado del plano de control con show control connections detail o show control connections-history detail. Si se detectan patrones sospechosos, por ejemplo conexiones en state up con challenge-ack 0, es recomendable escalarlo con Cisco TAC para confirmación y guía de respuesta. Si existe cualquier indicio de autenticación exitosa desde una IP desconocida o de peering no autorizado, conviene tratar el sistema como comprometido, abrir un caso con Cisco TAC incluyendo CVE-2026-20182 y evitar acciones disruptivas antes de recopilar artefactos.

En cuanto a hardening, la prioridad es reducir exposición: impedir el acceso directo desde Internet a UDP 12346 y TCP 830, y limitar esos puertos a las IP estrictamente necesarias del plano de control mediante filtrado y listas de permitidos. Para verificar persistencia, debe revisarse /home/vmanage-admin/.ssh/authorized_keys, eliminando claves no autorizadas y rotando credenciales y claves de administración si aparecen entradas sospechosas. También se recomienda auditar si se ha activado PermitRootLogin en /etc/ssh/sshd_config y buscar señales de encubrimiento, como borrados en syslog, wtmp, lastlog, bash_history o cli-history.

En vManage, la caza puede ampliarse revisando /var/log/nms/containers/service-proxy/serviceproxy-access.log en busca de accesos a data-collection-agent/.dca y solicitudes POST a rutas que terminen en .gz o .jsp, diferenciando respuestas HTTP 200 como una señal fuerte de ejecución de webshell. Asimismo, en /var/log/nms/vmanage-server.log conviene localizar eventos asociados a SmartLicensingManager que intenten escribir ficheros usando traversal ../ hacia despliegues de wildfly, registrando los nombres de payload detectados para su escalado.

La respuesta más efectiva combina parcheo inmediato y reducción de superficie. Además de CVE-2026-20182, es recomendable cerrar el resto de CVE relacionados con acceso inicial y cadenas publicadas, como CVE-2026-20133, CVE-2026-20128 y CVE-2026-20122, y abordar también escalados como CVE-2022-20775 cuando aplique. En un contexto en el que se han descrito múltiples clústeres oportunistas tras la publicación de PoC, mantener un enfoque de actualización integral y una verificación rigurosa de logs, claves y conexiones de control es clave para reducir el riesgo operativo en redes SD-WAN.

Más información

• BleepingComputer – Cisco warns of new critical SD-WAN flaw exploited in zero-day attacks : https://www.bleepingcomputer.com/news/security/cisco-warns-of-new-critical-sd-wan-flaw-exploited-in-zero-day-attacks/amp/
• Cisco Security Advisory – Cisco Catalyst SD-WAN Controller Authentication Bypass Vulnerability : https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-sdwan-rpa2-v69WY2SW
• Rapid7 – CVE-2026-20182: Critical authentication bypass in Cisco Catalyst SD-WAN Controller (FIXED) : https://www.rapid7.com/blog/post/ve-cve-2026-20182-critical-authentication-bypass-cisco-catalyst-sd-wan-controller-fixed/
• Help Net Security – Cisco patches another actively exploited SD-WAN zero-day (CVE-2026-20182) : https://www.helpnetsecurity.com/2026/05/15/cisco-sd-wan-zero-day-cve-2026-20182/
• Tenable – Frequently asked questions about the continued exploitation of Cisco Catalyst SD-WAN vulnerabilities (CVE-2026-20182) : https://www.tenable.com/blog/faq-about-the-continued-exploitation-of-cisco-catalyst-sd-wan-vulnerabilities-uat-8616
• The Hacker News – CISA Adds Cisco SD-WAN CVE-2026-20182 to KEV After Admin Access Exploits : https://thehackernews.com/2026/05/cisa-adds-cisco-sd-wan-cve-2026-20182.html
• Cisco Support – Remediate Catalyst SD-WAN Security Advisory (February 2026) : https://www.cisco.com/c/en/us/support/docs/routers/sd-wan/225525-internal-remediate-catalyst-sd-wan.html

La entrada Cisco corrige un bypass de autenticación crítico en Catalyst SD-WAN se publicó primero en Una Al Día.