Cisco parchea un zero-day explotado que reinicia firewalls ASA y FTD

Un firewall Cisco ASA o FTD actualizado en agosto para cerrar el reinicio forzado por la VPN SSL vuelve a ser vulnerable desde el 28 de octubre de 2026, cuando Cisco publicó el aviso de CVE-2026-76418, un segundo fallo de denegación de servicio en el mismo servicio de acceso remoto que ya se está explotando. Basta una petición manipulada al portal de la VPN SSL, sin credenciales, para que el equipo se reinicie, siempre que alguno de sus grupos de túnel tenga configurada la autenticación secundaria.

Una petición a la VPN SSL que tumba el firewall sin iniciar sesión

El aviso de Cisco (cisco-sa-asaftd-tunnel-dos-s6mgkb75, versión 1.0 y estado final) se publicó a las 19:15 GMT del 28 de octubre de 2026. Atribuye el fallo a errores de lógica en el servicio Remote Access SSL VPN de Cisco Secure Firewall ASA y Secure Firewall Threat Defense (FTD) cuando un grupo de túnel tiene configurado un servidor de autenticación secundaria. Un atacante remoto envía una petición manipulada mientras se conecta a la VPN SSL y el dispositivo se recarga. Cisco lo dice de forma literal: «A successful VPN login is not required to reach the affected processing path» (no hace falta iniciar sesión en la VPN para llegar a la ruta de procesamiento afectada).

La debilidad está catalogada como CWE-690, un valor de retorno sin comprobar que termina en una desreferencia de puntero nulo, y lleva el identificador interno CSCwx26625. La puntuación CVSS 3.1 es 8,6 con el vector AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H, el mismo que Cisco asignó en agosto a CVE-2026-20349. El impacto se limita a la disponibilidad, pero con alcance cambiado, porque el reinicio del firewall corta todas las sesiones VPN activas y el tráfico que cruza el equipo, más allá del servicio atacado.

NVD recibió el registro a las 20:18 UTC del 28 de octubre y en el momento de escribir esta noticia, la tarde del 29 de octubre, lo mantiene en estado Received, con la puntuación del CNA (Cisco) y sin análisis propio. Su ficha en NVD tampoco mostraba los campos del catálogo KEV, y la versión del catálogo publicada por CISA a las 19:00 UTC del 28 de octubre no incluía el CVE. La explotación la confirma el propio fabricante en el apartado de anuncios públicos: «In October 2026, the Cisco PSIRT became aware of active exploitation of this vulnerability» (en octubre de 2026, el PSIRT de Cisco tuvo conocimiento de la explotación activa de esta vulnerabilidad). No hay indicadores de compromiso, ni descripción de los ataques, ni atribución. Cisco acredita el hallazgo a Eric Fernald durante la resolución de un caso de soporte del TAC, lo que apunta a un cliente cuyo firewall ya se reiniciaba sin motivo aparente.

Qué configuración de ASA y FTD está expuesta y cómo comprobarla

No todos los ASA y FTD con VPN SSL están afectados. Cisco exige tres condiciones a la vez: una versión sin corregir, el servicio de inicio de sesión de la VPN SSL accesible y la autenticación secundaria configurada en el ámbito de grupo de túnel que describe el aviso. La captura del propio aviso muestra la tabla de configuración vulnerable, que se reduce a la palabra webvpn con el comando enable sobre al menos una interfaz.

La parte que exige leer con cuidado es la de los grupos de túnel. Si la configuración incluye tunnel-group-list enable, hay que revisar todos los grupos, incluido el grupo por defecto DefaultWEBVPNGroup, en busca de secondary-authentication-server-group, y Cisco avisa de que la comprobación no se limita a los perfiles que aparecen en la lista desplegable de la página de inicio de sesión. Si la lista de grupos está desactivada, el equipo sigue expuesto cuando DefaultWEBVPNGroup usa autenticación secundaria. En FTD, la configuración resultante se revisa en la política de acceso remoto desplegada desde Secure Firewall Management Center (FMC) o Firewall Device Manager (FDM). Quedan fuera Cloud-delivered Firewall, cdFMC, Secure Access y el propio software de Secure FMC.

Estos comandos sirven para localizar en un ASA, o en la configuración en ejecución de un FTD, las tres piezas que combina el aviso.

show running-config webvpn
show running-config tunnel-group | include ^tunnel-group|secondary-authentication-server-group
show running-config all tunnel-group DefaultWEBVPNGroup | include secondary-authentication

Si la primera salida contiene enable sobre una interfaz exterior y cualquiera de las otras dos devuelve un servidor de autenticación secundaria, el equipo cumple las condiciones del aviso y la única salida definitiva es actualizar. La autenticación secundaria, habitual en despliegues que combinan un directorio con un segundo factor por RADIUS, es justo la configuración que las guías de acceso remoto por VPN recomiendan, y aquí se convierte en la condición que hace explotable el fallo.

Más de 51.000 VPN SSL de ASA a la vista en Shadowserver

Cisco no da cifras de equipos afectados. La única medida de exposición disponible la publicó BleepingComputer el 29 de octubre a partir de los escaneos de The Shadowserver Foundation, que cuenta más de 51.000 dispositivos Cisco ASA con la VPN SSL expuesta en internet, sin distinguir cuántos ya están parcheados ni cuántos son señuelos. El mapa reparte esa población por países.

Estados Unidos concentra unos 24.000 equipos, seguido de Alemania, Reino Unido y Japón con unos 3.000 cada uno y Canadá con unos 2.000. En Europa occidental, la etiqueta situada sobre España marca 304 dispositivos, por debajo de Francia (528) e Italia (708). La cifra mide la población visible de ASA con portal SSL VPN, no la que cumple la condición de autenticación secundaria, así que el número real de equipos explotables es menor y nadie lo ha publicado en el momento de escribir esta noticia. Tampoco hay, de momento, un informe de GreyNoise, Censys o Shodan específico para este CVE.

En España, INCIBE-CERT publicó el 29 de octubre el aviso INCIBE-2026-806, con importancia 5 (crítica) porque agrupa CVE-2026-76418 con las vulnerabilidades de Node.js que Cisco corrige en sus productos, entre ellas el fallo de Brotli CVE-2026-111497 que ya seguimos en el blog. El detalle del CVE de la VPN SSL dice «Cisco confirma su explotación activa», aunque la tabla final del aviso marca No en la columna de explotación para los cinco CVE. INCIBE añade una nota que explica que ese valor corresponde al momento de publicación y puede haber cambiado.

Segundo reinicio forzado desde agosto y una fila más en KEV

CVE-2026-76418 es el segundo fallo de denegación de servicio en la VPN SSL de ASA y FTD que se explota como zero-day en menos de tres meses. El 11 de agosto de 2026, Cisco publicó el aviso de CVE-2026-20349, un error de inspección de memoria (CWE-244) en el procesamiento de peticiones HTTP del mismo servicio, con idéntica puntuación de 8,6 y una explotación de la que el PSIRT tuvo noticia ese mismo mes. CISA lo incorporó a su catálogo KEV el 11 de agosto con plazo hasta el 14 de agosto, bajo la directiva BOD 26-04. Aquel aviso acreditaba el hallazgo a las pruebas internas de Cisco y al investigador Valerio Brussani.

Las versiones corregidas de agosto no cubren el fallo de octubre. La comparación de los dos avisos, rama por rama, deja a quien actualizó en agosto una compilación por detrás.

El catálogo KEV de CISA, descargado el 28 de octubre, contiene 101 vulnerabilidades de Cisco, 19 de ellas incorporadas en 2026, y 14 corresponden a ASA o FTD. Entre las de la familia están las dos de ArcaneDoor de abril de 2024 (CVE-2024-20353 y CVE-2024-20359), las dos de septiembre de 2025 que motivaron la directiva de emergencia ED 25-03 (CVE-2025-20333 y CVE-2025-20362) y CVE-2023-20269, la única de ASA que CISA asocia a campañas de ransomware conocidas. El patrón de este otoño en Cisco va más allá del firewall: el 14 de octubre entró en KEV el fallo de Secure Email Gateway que da root con un adjunto, y esta misma mañana contábamos cómo KeyDrift extrae el material criptográfico desde dentro de los controladores de Catalyst SD-WAN.

Lo que Cisco no cuenta pesa tanto como lo que cuenta. Un reinicio forzado y repetido de un firewall perimetral es, en sí mismo, un incidente de disponibilidad, pero en los casos de 2024 y 2025 los fallos de denegación de servicio de ASA aparecieron junto a cadenas de acceso y persistencia, y aquí no hay información para saber si ocurre lo mismo. Hasta que el fabricante o una agencia publiquen más datos, nuestra lectura es tratar cada reinicio inesperado de un ASA o FTD con VPN SSL expuesta como un posible intento de explotación y conservar los registros, como ya recomendábamos para los zero-days de PAN-OS explotados este mes.

Versiones que cierran CVE-2026-76418 y orden de trabajo para esta semana

Las tablas del aviso, reproducidas abajo, dan la primera versión corregida de cada rama. En ASA son 9.16.4.104 (para 9.16 y anteriores), 9.18.4.96, 9.20.4.50, 9.22.3.200, 9.23.1.48 y, en la rama 9.24, 9.24.1.27 o 9.24.10.1. En FTD, 7.0.11 (para 7.0 y anteriores), 7.2.13, 7.4.9, 7.6.7, 7.7.14, 10.0.3 y 10.1.1. Para despliegues con varias ramas, el Cisco Software Checker devuelve la primera versión que cierra a la vez este aviso y los demás que afecten a la versión instalada.

1. Inventaria hoy todos los ASA y FTD con webvpn activo en una interfaz exterior y ejecuta los comandos de comprobación de arriba. Anota cuáles tienen secondary-authentication-server-group en cualquier grupo de túnel o en DefaultWEBVPNGroup.
2. Actualiza esos equipos a la primera versión corregida de su rama, empezando por los que cumplen las tres condiciones del aviso, y comprueba después con show version que la compilación instalada es igual o posterior a la de la tabla.
3. Revisa la lista de crashinfo y el tiempo de actividad de cada equipo (show crashinfo y show version | include up) desde el 1 de octubre, y busca en el syslog los mensajes de recarga sin ventana de mantenimiento asociada.
4. Si no puedes actualizar en días, aplica la mitigación de Cisco que corresponda a tu configuración, pero solo después de valorar lo que pierdes.
5. Comunica los reinicios sospechosos a INCIBE-CERT (empresas) o al CCN-CERT (sector público), con el crashinfo y los registros de la VPN del intervalo afectado.

Cisco describe dos mitigaciones, válidas solo mientras llega la actualización, y advierte de que la segunda rebaja la seguridad del acceso remoto. Si DefaultWEBVPNGroup no usa autenticación secundaria, se desactiva la lista de grupos de túnel, y los usuarios dejan de ver el desplegable de perfiles y tienen que conocer el nombre del suyo. Si el grupo por defecto sí la usa, se retira el servidor de autenticación secundaria. Cisco documenta los dos cambios en la configuración de webvpn y del grupo por defecto.

webvpn
 no tunnel-group-list enable
!
tunnel-group DefaultWEBVPNGroup general-attributes
 no secondary-authentication-server-group

El fabricante señala que la mitigación se ha probado en un entorno de laboratorio y pide a cada cliente que evalúe su aplicabilidad antes de desplegarla. Quitar el segundo factor de la VPN para evitar un reinicio es un cambio que conviene documentar, acotar en el tiempo y deshacer en cuanto el equipo esté en una versión corregida, y las interfaces de administración y de VPN de un firewall merecen el mismo tratamiento que repasamos en nuestra guía para optimizar la ciberseguridad del firewall. En la campaña FortiBleed, la VPN SSL sin doble factor fue precisamente la puerta de entrada.

La vulnerabilidad salió de un caso de soporte, no de una investigación. Alguien tenía un firewall que se reiniciaba, abrió un ticket y el ingeniero que lo atendió encontró el fallo. Esa es la medida real de lo que había en marcha antes del aviso del 28 de octubre.