Hay una jerarquía no escrita en la que casi todos hemos caído: si te roban datos es un incidente grave, si te modifican datos es un incidente grave, y si te tumban el equipo… bueno, es una caída. Se llama a soporte, se reinicia y a otra cosa. El aviso que Cisco publicó el 11 de agosto viene a discutir esa jerarquía, y CISA la discutió aún más fuerte: dos horas y veinte minutos después de que saliera el aviso, el fallo estaba en el catálogo de vulnerabilidades explotadas con fecha límite a tres días.
No somos revendedores de Cisco ni de ningún otro fabricante de cortafuegos, así que esto no va de defender a nadie. Va de la conversación que toca tener con cualquiera que tenga un concentrador de VPN de acceso remoto en el perímetro de su red: la disponibilidad no es la hermana menor de la confidencialidad. Es la que te toca casi siempre.
Qué hace exactamente el fallo
CVE-2026-20349 afecta a Cisco Secure Firewall ASA y a Secure Firewall Threat Defense (FTD). La causa, según el aviso, es una comprobación de errores insuficiente al procesar peticiones HTTP: un atacante remoto y sin autenticar envía una petición preparada contra el servicio de VPN SSL de acceso remoto y el aparato se reinicia. Nada más, y nada menos. El vector lo dice sin adornos: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H, puntuación base 8.6. Confidencialidad, ninguna. Integridad, ninguna. Disponibilidad, alta.
Conviene decir una cosa que un lector técnico va a ver enseguida: tanto el aviso como el catálogo de CISA clasifican el fallo como CWE-244, que es una categoría de exposición de información, y CISA lo titula «Heap Inspection Vulnerability». Suena a fuga. Pero la descripción del propio aviso habla de comprobación de errores al procesar HTTP, y el vector cierra la puerta a la interpretación: C:N/I:N. Nos quedamos con el vector, que es lo que Cisco firma sobre el impacto.
El aviso pone dos condiciones a la vez: versión afectada y alguna de estas tres configuraciones, que son las que pueden levantar los sockets SSL de escucha. Se comprueba mirando la configuración:
- •VPN de acceso remoto IKEv2 con servicios de cliente:
crypto ikev2 enable <interfaz> client-services port <puerto>. - •VPN SSL:
webvpn enable <interfaz>. - •Zero Trust Network Access, solo en FTD:
zero-trust enable.
Cisco ha sacado hot fix para ASA 9.16, 9.18, 9.20, 9.22, 9.23 y 9.24, y para FTD 7.0, 7.2, 7.4, 7.6, 7.7 y 10.0; para tu build exacta el aviso remite a su Software Checker. El Management Center (FMC) no está afectado. Y la frase que le quita a cualquiera la opción de improvisar: «no hay soluciones alternativas que corrijan esta vulnerabilidad». No hay ACL milagrosa ni parámetro que apagar sin apagar también el servicio. O parcheas, o dejas de dar VPN.
Cisco publicó el aviso el 11 de agosto a las 16:39 GMT y dice que su PSIRT tuvo conocimiento de explotación activa en agosto de 2026. No ha dado detalles: ni quién explota, ni contra quién, ni cuántos. Eso, en la práctica, significa una sola cosa útil: alguien ya tiene el método que funciona.
El reloj del 11 de agosto
Las horas de ese día cuentan la historia mejor que la puntuación. Cisco publicó el aviso a las 16:39 GMT. La versión del catálogo de vulnerabilidades explotadas conocidas (KEV) que lo incluye lleva marca de tiempo de las 18:59 GMT del mismo día. Con esa versión entraron tres vulnerabilidades, ni una más, y salieron con dos fechas límite distintas:
- •CVE-2026-20349 (Cisco ASA/FTD) — plazo: 14 de agosto. Tres días.
- •CVE-2026-72898 (Metabase) — plazo: 14 de agosto. Tres días también, y de ese escribimos aquí el lunes, cuando todavía no tenía CVE asignado.
- •CVE-2026-68820 (controlador AFD de Windows) — plazo: 25 de agosto. Catorce días.
La acción requerida del catálogo remite a la directiva BOD 26-04, que sustituyó el plazo único que había antes por una priorización basada en riesgo: exposición, facilidad de automatización, impacto y evidencia de explotación. Traducido: lo que está en el perímetro, mira a Internet y se explota sin autenticación sube al escalón corto. El que decide el plazo ya no es la gravedad del daño, es la facilidad de llegar hasta ti. Y un servicio de VPN publicado a Internet es, por definición, el sitio más fácil al que llegar.
Esos plazos obligan a las agencias civiles del Ejecutivo federal estadounidense, no a una empresa de Manresa ni de Barcelona. Pero llevamos tiempo usando el catálogo como lo que realmente es: una lista de lo que ya se está explotando ahí fuera, hecha por gente que no vende parches. Cuando algo entra en KEV con tres días, la pregunta interesante no es si te obliga. Es qué sabe CISA que a ti no te han contado.
Un reinicio aquí no es una molestia: es el interruptor de tu plantilla
Un servidor web que se cae molesta. Un concentrador de VPN que se cae hace otra cosa: deja fuera a todo el que no está físicamente en la oficina. Comerciales, técnicos de campo, la gente que teletrabaja, el proveedor que iba a conectarse a hacer un mantenimiento, y —esta es la que duele— el propio equipo de sistemas que necesita entrar para arreglarlo. Si tu plano de gestión pasa por el mismo túnel que acaba de reiniciarse, no tienes un incidente de red: tienes un incidente de red y además estás ciego.
Es el mismo razonamiento que aplicamos con los zero-days de los portales VPN perimetrales: el aparato que pusiste para que nadie entrara sin permiso es, a la vez, el punto que apaga el trabajo de todos si se cae. Esa doble condición no la tiene casi ningún otro equipo de tu red.
Y el parche también corta
Esta es la trampa operativa que casi nadie menciona cuando escribe «parchea ya». Actualizar un concentrador de VPN corta las sesiones activas. Si tienes un par en alta disponibilidad y el ciclo bien ensayado, se hace con molestia menor. Si tienes un único aparato —que es lo más habitual en una pyme— la mitigación cuesta exactamente lo mismo que el ataque: la gente fuera un rato. La diferencia es que el rato lo eliges tú.
Y conviene leerse la letra pequeña antes de la ventana, no durante. Cisco ha sacado hotfixes por rama y por plataforma (para FTD hay variantes según el modelo), y avisa de un detalle que puede arruinar una madrugada: en los hotfixes cuya numeración empieza por «89» hay que instalar también ASDM 7.24.1.374, porque las versiones anteriores de ASDM no reconocen el nuevo formato de numeración de ASA. Un equipo parcheado al que luego no puedes gestionar por consola gráfica es un problema nuevo, creado a las cuatro de la mañana.
Lo que miramos nosotros cuando cae un aviso así
Parchear es la parte fácil y la que todo el mundo escribe. Lo que separa una tarde movida de un día perdido es lo de al lado:
- ✓Qué versión llevas de verdad, no la que pone el inventario. La rama y el build, comparados con la tabla del aviso.
- ✓Si el socket está realmente levantado. Un ASA sin VPN de acceso remoto habilitada no es vulnerable a esto, y decirlo evita ventanas de mantenimiento innecesarias.
- ✓Quién se queda fuera durante la ventana y quién no puede quedarse fuera. Guardias, turnos de noche, gente en otro huso horario, integraciones de proveedor. Esa lista casi nunca está escrita, y es la que decide la hora.
- ✓La segunda vía de acceso al plano de gestión, independiente del túnel que estás tocando. Una consola fuera de banda, un salto por otro camino, algo. Si la única forma de entrar es la que vas a reiniciar, no tienes plan: tienes fe.
- ✓Qué se puede detectar mientras se abre la ventana. El aviso enlaza dos reglas de Snort (46897 y 59654). No son una solución alternativa —no la hay— pero responden a la pregunta que hace todo el mundo: si no puedo parchear hasta el sábado, ¿al menos me entero?
- ✓Cuánto tarda de verdad en volver. No la estimación: el tiempo medido la última vez. Si nadie lo ha medido nunca, la ventana de esta noche es la ocasión de medirlo.
Cuándo esto no va contigo
Lo decimos porque el ruido de estos días hace que mucha gente corra sin motivo: si no tienes ASA ni FTD, esto no va contigo. Si los tienes pero sin ninguna de las tres configuraciones del aviso —solo túneles sitio a sitio, y sin Zero Trust levantado en el FTD—, tampoco. Y si ya estás en una versión con el hot fix aplicado, has terminado. La lectura que sí vale para todos es la otra, y no caduca con este CVE: revisa qué pasa en tu empresa el día que el acceso remoto no está. Ese ensayo no depende del fabricante que tengas en el borde.
Al grano
Un fallo que no roba nada acaba de recibir el mismo plazo que se le da a lo peor del catálogo, porque lo que se mide ya no es qué te hacen sino desde dónde pueden hacerlo. En tu caso el plazo no lo firma nadie: lo firmas tú. Y la pregunta que deja este aviso, cuando el hotfix ya esté puesto, es la de siempre: si mañana el acceso remoto no arranca, ¿cuánta gente de tu empresa no puede trabajar, y cuánto tardarías en enterarte?
Fuentes (consultadas el 14 de agosto de 2026): descripción del fallo, vector CVSS, configuraciones vulnerables, ausencia de soluciones alternativas, versiones afectadas, nota sobre ASDM 7.24.1.374, clasificación CWE-244, reglas de Snort enlazadas y conocimiento de explotación activa por parte del PSIRT — aviso de seguridad de Cisco cisco-sa-asaftd-vpn-dos-dzv4mQFF; fechas de alta y plazos de las tres entradas del 11 de agosto y referencia a la directiva BOD 26-04 — catálogo KEV de CISA (datos leídos directamente del fichero JSON publicado); criterios de priorización por riesgo — BOD 26-04. Cisco no ha publicado información sobre atacantes ni víctimas; cualquier afirmación sobre campañas concretas hoy sería especulación.
¿Cuánto aguanta tu empresa sin acceso remoto?
En everyWAN trabajamos el cumplimiento y la continuidad como lo que son: un ensayo, no un documento. Miramos qué se cae contigo, quién se queda fuera y por dónde entras cuando la puerta de siempre no está.
Hablar con everyWAN
Microsoft 365
ES 
CAT 
EN