El aviso de Cisco del 28 de octubre dice dos cosas en la misma página. Una: «no hay soluciones alternativas que resuelvan esta vulnerabilidad». La otra, más abajo: puedes mitigarla retirando la autenticación secundaria del grupo de túnel, y el propio aviso reconoce que eso reduce tu postura de seguridad. Las dos están ahí, y el aviso no elige por ti.
Es CVE-2026-76418, en el servicio de VPN SSL de acceso remoto de Cisco Secure Firewall ASA y FTD. Un atacante sin autenticar manda una petición preparada y el cortafuegos se recarga. Puntúa 8,6 y el PSIRT dice haber tenido noticia de explotación activa antes de publicar el aviso. Sobre lo que significa que un fallo de este servicio solo afecte a la disponibilidad lo contamos entonces, cuando en agosto pasó algo muy parecido; este post va de la parte que en agosto no existía.
Qué pide el aviso para considerarte vulnerable
Tres condiciones, y las tres salen de la configuración en marcha, no del inventario:
- 1Hay un bloque
webvpnen la configuración. - 2Dentro hay un
enable <interfaz>, es decir, la VPN SSL de acceso remoto está habilitada en al menos una interfaz. - 3Algún grupo de túnel tiene
secondary-authentication-server-group.
Si falla cualquiera de las tres, el aviso no te aplica. Eso es más gente de la que parece, y por eso la tercera condición merece su propio apartado: se está leyendo mal en casi todas partes.
secondary-authentication no es lo mismo que «tener MFA»
La condición es ese comando, literalmente, no la idea de tener un segundo factor. Y son cosas distintas. En muchos despliegues el doble factor se resuelve con un único grupo de autenticación —un RADIUS que por dentro hace la contraseña y el empujón al móvil, o SAML contra el proveedor de identidad— y entonces no existe ningún secondary-authentication-server-group en la configuración. Ese montaje no cumple la tercera condición, por mucho MFA que tengan tus usuarios.
Lo decimos porque la lectura que circula —«si pusiste doble factor, te toca»— va a mandar a gente a una ventana de servicio que no necesita. Lo que decide no es tu política de identidad: es si ese comando aparece al leer la configuración. Compruébalo antes de mover nada.
El grupo que nadie creó a mano
Hay una instrucción del aviso que se salta casi todo el mundo. Si tienes tunnel-group-list enable, Cisco pide revisar todos los grupos de túnel, y nombra expresamente DefaultWEBVPNGroup. Es el grupo que viene de fábrica, el que nadie creó a propósito y el que no aparece cuando preguntas al equipo qué grupos hay montados. Si alguien le puso autenticación secundaria en algún momento —o se la dejó puesta una migración de hace seis años— cumples la tercera condición sin saberlo.
Qué pierdes con cada opción
Si cumples las tres condiciones, el menú del aviso es este:
| Opción | Qué te cuesta | Qué te deja |
|---|---|---|
| Actualizar | Una ventana de servicio, con su corte | El fallo cerrado y la autenticación como estaba |
| Mitigar | La autenticación secundaria de ese grupo de túnel | Un equipo que ya no se recarga, y una puerta con una vuelta de llave menos |
| Esperar | Nada hoy | El mismo corte, a la hora que elija otro |
La fila del medio es la que conviene mirar dos veces. Cisco la ofrece y a la vez recomienda actualizar, porque sabe lo que cuesta. Si la usas, que sea como paso de unas horas, con fecha de caducidad escrita en el ticket y en el calendario de alguien con nombre. Un doble factor retirado «mientras tanto» es la clase de cambio que sigue ahí dos años después porque nadie recuerda por qué se hizo.
El segundo del mismo servicio desde agosto
El 11 de agosto de 2026 Cisco avisó de CVE-2026-20349: mismo producto, mismo servicio de VPN SSL de acceso remoto, misma puntuación de 8,6, mismo atacante sin autenticar y también explotado antes del aviso, por comprobación de errores insuficiente al procesar peticiones HTTP. Entre aquel aviso y este han pasado 78 días. Los plazos que CISA dio en los dos casos fueron de tres días —el de ahora vence el 1 de noviembre, que cae en domingo— y sobre esa aritmética de fines de semana ya contamos los días sobre el propio fichero de CISA.
Dos avisos no son una tendencia estadística, y no vamos a vendértelo como tal. Pero sí cambian la pregunta de planificación: si el mismo servicio te ha pedido una ventana de urgencia dos veces en once semanas, el calendario de parcheo que tenías escrito para él se ha quedado corto.
Si vas a casar identificadores para un informe
Un apunte práctico que nos encontramos al descargar el catálogo de CISA y que no hemos visto citado: las dos fuentes no llaman igual al mismo fallo. El catálogo titula la entrada de CVE-2026-76418 como «desreferencia de puntero nulo por valor de retorno sin comprobar», mientras que la prosa del aviso de Cisco habla de «errores de lógica». Con el de agosto pasa lo mismo: CISA lo cataloga como «vulnerabilidad de inspección de montículo» y Cisco describe otra cosa. No es contradictorio —una puede ser la causa raíz de la otra— pero si estás montando un informe que cruza ambas fuentes, esperar el mismo texto te va a costar un rato.
Sobre la cifra que circula estos días: Shadowserver ve más de 51.000 dispositivos Cisco ASA con la VPN SSL expuestos a internet. Lo apunta el propio medio que la publica y conviene repetirlo: eso cuenta servicios visibles, no equipos vulnerables. No distingue versión, no sabe cuáles tienen autenticación secundaria configurada —que es la tercera condición— y no separa los señuelos. Es una medida de superficie, no un recuento de víctimas.
Lo que el parche no cambia
Las versiones corregidas de ASA son 9.16.4.104 para la rama 9.16 y anteriores, 9.18.4.96, 9.20.4.50, 9.22.3.200, 9.23.1.48 y 9.24.1.27 (o 9.24.10.1) según la rama en la que vivas. Actualiza. Pero cuando cierres la ventana seguirás teniendo delante dos preguntas que el parche no toca:
- →Por dónde entras a arreglarlo. Si el camino de administración pasa por el aparato que hay que administrar, no tienes acceso de emergencia. Una vía fuera de banda existe exactamente para noches como esta.
- →Qué más termina en esa caja. Usuarios remotos, túneles entre sedes y acceso de proveedores suelen acabar en el mismo sitio por comodidad, y entonces se van juntos. Y un enlace de respaldo que termina en el mismo equipo con la misma versión no es un segundo camino: ya escribimos sobre por qué dos caminos solo cuentan como dos si no comparten nada.
Repartir esas piezas —que el acceso de usuarios y el de sedes no vivan en la misma caja, que el plano de administración tenga puerta propia— es trabajo de diseño de red y comunicaciones. Cuando hay varias sedes de por medio, es la conversación de una SD-WAN bien planteada: varios caminos, conmutación automática y la política escrita en un sitio.
Cómo lo miramos nosotros
No somos resellers de ningún fabricante de cortafuegos: recomendamos según el caso, no según la comisión. Somos operador con red propia —BGP, tránsito y peering, con el looking glass público en lg.everywan.com— y montamos acceso remoto e interconexión de sedes con WireGuard y SD-WAN según el caso. Cuando cae un aviso así, dos cosas nos ahorran la noche: la red documentada en NetBox, que convierte «¿a cuántos sitios nuestros les toca esto?» en una consulta en vez de una ronda de correos; y una monitorización —Zabbix y SmokePing, con alertas que importan y no ruido— que distingue un equipo que se ha recargado de un equipo que responde al ping.
Y una cosa que haríamos aunque no cumplas las tres condiciones: leerte la configuración entera de los grupos de túnel esta semana. No por este fallo, sino porque si hay que mirarla con prisa el domingo por la mañana, ya has perdido la parte difícil.
Fuentes (verificadas el 30 de octubre de 2026): Aviso de seguridad de Cisco cisco-sa-asaftd-tunnel-dos-s6mgkb75, publicado el 28-10-2026 a las 19:15 GMT, versión 1.0 final — de ahí salen CVE-2026-76418, la puntuación base 8,6 con vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H, la causa («logic errors when secondary authentication is configured on a tunnel group»), las tres condiciones de producto vulnerable (webvpn con enable en una interfaz, secondary-authentication-server-group, y la revisión de todos los grupos incluido DefaultWEBVPNGroup cuando hay tunnel-group-list enable), la frase «there are no workarounds that address this vulnerability» junto con la mitigación y su advertencia de impacto en la seguridad, las versiones corregidas (9.16.4.104, 9.18.4.96, 9.20.4.50, 9.22.3.200, 9.23.1.48, 9.24.1.27 / 9.24.10.1) y la nota de explotación activa en octubre de 2026. Datos del fallo de agosto: aviso cisco-sa-asaftd-vpn-dos-dzv4mQFF (CVE-2026-20349, 11-08-2026, 8,6, comprobación de errores insuficiente al procesar peticiones HTTP al servicio de VPN SSL de acceso remoto). Fechas de alta y plazos: catálogo de vulnerabilidades explotadas de CISA, versión 2026.10.29 con 1.764 entradas, descargada y leída por nosotros — CVE-2026-76418 con alta el 29-10-2026 y plazo 01-11-2026, titulada allí «Unchecked Return Value to NULL Pointer Dereference»; CVE-2026-20349 con alta el 11-08-2026, plazo 14-08-2026 y titulada «Heap Inspection Vulnerability». La cifra de más de 51.000 ASA con VPN SSL expuestos, y la advertencia de que no equivale a equipos vulnerables, son de BleepingComputer (29-10-2026). Los 78 días entre el 11 de agosto y el 28 de octubre y el apunte sobre la diferencia de denominación entre CISA y Cisco son aritmética y lectura nuestras. La distinción entre secondary-authentication-server-group y «tener MFA», la tabla de opciones y las dos preguntas de diseño también son nuestras.
¿Sabes hoy qué grupos de túnel tienes y qué autenticación lleva cada uno?
En everyWAN diseñamos y operamos el acceso remoto y la interconexión de sedes de empresas que no se pueden permitir una tarde a oscuras. Te hacemos el mapa de qué depende de qué y te decimos dónde está la pieza única.
Hablar con everyWAN
Microsoft 365
ES 
CAT 
EN