Volver al Blog

Diez CVE en el mismo proceso: el titular no basta para decidir

Armario de comunicaciones de pared en el cuarto trasero de una sede, con un conmutador, un panel de parcheo y cables de red

Hay un aviso, entre los diez que WatchGuard publicó el 27 de agosto sobre iked, que se titula «Allows Unauthenticated Denial of Service». Su propio campo de impacto, cuatro líneas más abajo, empieza así: «A remote, authenticated IKEv2 peer (a legitimate VPN user with valid credentials…)». El titular dice «sin autenticar». El cuerpo dice «usuario de tu VPN con credenciales válidas». Los dos están en la misma página, y solo uno de los dos sirve para decidir si esta noche llamas a alguien.

Diseñamos y operamos redes multisede con túneles IPsec, así que un boletín como este acaba en nuestra mesa varias veces al mes. Este nos pareció digno de contarse porque es grande —diez fallos en un solo proceso, publicados el mismo día— y porque al leerlo entero, ficha a ficha, se deshace en algo bastante distinto de lo que sugiere el recuento. No va de asustar con un fabricante: el que tienes tú en la pared da igual de quién sea, y el método sirve para cualquiera. Todo lo que sigue sale de las diez fichas públicas del PSIRT del propio fabricante y de un par de fuentes más, todas citadas al final.

Qué es iked y por qué diez es mucho

iked es el demonio que habla IKE, el protocolo con el que dos extremos acuerdan las claves de un túnel IPsec: el que levanta la VPN entre la central y cada delegación y el que atiende al portátil que se conecta desde un hotel. Para hacer ese trabajo tiene que leer paquetes de una dirección que todavía no ha autenticado; no puede ser de otra manera, porque la autenticación es justo lo que se está negociando. Por eso una tanda de fallos ahí se lee distinto que en el panel de administración, que se restringe a cuatro direcciones y se acabó.

El índice del PSIRT del fabricante lista veintiocho avisos fechados el 27 de agosto de 2026: dieciséis de Dimension, su plataforma de informes, y doce de Fireware OS, el sistema del cortafuegos. De esos doce, diez están en iked. Tres se titulan ejecución remota de código, los tres con 9,3 en CVSS v4; seis se titulan denegación de servicio con 8,7, y uno con 6,9. Nueve de los diez se corrigen en Fireware OS 2026.2.2, 12.12.2 y 12.5.20 para los modelos T15 y T35; el de 6,9 ya estaba cerrado en la entrega anterior de cada rama. Y el fabricante afirma en las diez fichas que no tiene constancia de explotación en el mundo real.

La palabra que se cae del titular

Los tres avisos de 9,3 se titulan «Allows Remote Code Execution». Ninguno de los tres cuerpos afirma que se haya ejecutado código. El del desbordamiento de montículo dice «causing a crash and denial of service, with the potential for remote code execution». El de la confusión de tipos dice que provoca la caída del demonio y que, por cómo llega a un free() sobre un puntero influido por el atacante, «may also present potential for further memory corruption and remote code execution». El tercero, «may carry potential for remote code execution». Tres veces «potencial», tres veces fuera del titular.

Esto no los vuelve inofensivos y no lo estamos diciendo. Dos de los tres tumban iked desde fuera sin pedir nada, y tumbar iked es dejar sin túneles a las sedes y sin VPN a la gente de fuera; con esos dos basta un mensaje IKE_AUTH bien construido. Al tercero le hace falta además un interruptor de diagnóstico encendido, y a eso volvemos enseguida. Lo que cambia es la frase que le dices a dirección. «Nos pueden ejecutar código en el cortafuegos» y «nos pueden tirar las VPN, y hay indicios de que podría llegar a más» no son la misma conversación, y solo una de las dos está respaldada por el documento.

Los diez, leídos por lo que hace falta para alcanzarlos

Un titular describe la clase del fallo —desbordamiento de pila, doble liberación, subdesbordamiento de entero— y la puntuación resume su gravedad en abstracto. La decisión, en cambio, depende de otra cosa: qué tiene que tener el atacante para llegar hasta ahí. Eso solo está en el cuerpo, y en esta tanda no es igual en los diez.

CVE Lo que dice el titular Lo que hace falta, según el cuerpo
19313 · 9,3RCE sin autenticarNada. Tráfico construido, sin condición previa en la ficha
19315 · 9,3RCE sin autenticarUn IKE_AUTH con dos cargas EAP
19318 · 9,3RCE sin autenticarQue el registro de diagnóstico de cargas IKE esté ENCENDIDO
19316 · 8,7DoS sin autenticarUn solo paquete UDP. Cae y vuelve a arrancar solo
19317 · 8,7DoS sin autenticarUn IKEv2 malformado. Afecta a VPN móvil y de sedes
78011 · 8,7DoS sin autenticarUn paquete UDP IKEv1. Confirmado con prueba de concepto
78009 · 8,7DoS sin autenticarNada más que completar el SA_INIT. Y podría exponer material de claves
78010 · 8,7DoS SIN AUTENTICARSer un usuario de tu VPN con credenciales válidas
19314 · 8,7DoS sin autenticar«Si es explotable». El fabricante no logró reproducirlo
81851 · 6,9DoSSer administrador autenticado y guardar una configuración

Leída así, la tanda se ordena sola. Seis los alcanza un desconocido desde internet sin nada. Uno pide que alguien haya dejado encendido un interruptor de diagnóstico. Uno pide credenciales válidas de tu propia VPN, que es un escenario real —un empleado, un portátil robado, un proveedor— pero no el mismo escenario. Uno pide ser administrador del aparato, es decir, alguien que ya puede hacer mucho más daño abriendo el menú. Y uno el propio fabricante escribe que «internal verification against a fixed build using a reconstructed proof-of-concept did not reproduce an iked crash»: lo publica igualmente, con su 8,7 puesto, y nos parece bien que lo publique; pero conviene saber que está ahí.

El que miraríamos primero no es ninguno de los tres de 9,3

El aviso que más nos inquieta de los diez es el CVE-2026-78009, que va con 8,7 y se titula, otra vez, denegación de servicio. Su cuerpo dice que un atacante sin autenticar que complete el intercambio inicial puede enviar un mensaje INFORMATIONAL cifrado con una carga DELETE malformada y hacer que iked lea hasta unos 196 KiB más allá del final de una reserva de montículo. Y sigue: además de tumbar el proceso de forma fiable, «could potentially expose adjacent heap memory (e.g., other IKE SA key material or certificate data) to an attacker under favorable heap layout conditions».

Un proceso que se cae vuelve a arrancar; la propia ficha de varios de estos avisos lo dice, crash and respawn. Material de claves que sale por la puerta no vuelve. Un condicional apilado sobre otro —«podría», «en condiciones favorables»— es exactamente el tipo de frase que no justifica una alarma a las tres de la mañana, y por eso no vamos a decir que lo sea. Pero de los diez, es el único cuya consecuencia sobrevive al reinicio sin depender de que un «potencial» se cumpla, y va por debajo en la lista si ordenas por puntuación. Ordenar por CVSS es ordenar por gravedad genérica; ordenar por «qué queda cuando esto termina» da otro orden.

Quién los encontró, que también se publica

Las fichas traen el crédito, y el reparto explica bastante. Seis de los diez llevan el nombre de un investigador de una firma externa de seguridad ofensiva. Tres —los tres de la serie 780xx— dicen literalmente «Discovered Internally by WatchGuard AI Security Research». Y el décimo, el de 6,9, es de un investigador independiente. O sea que los diez no aparecieron el 27 de agosto: se publicaron el 27 de agosto, y salieron de dos campañas distintas que apuntaron al mismo demonio.

Nuestra lectura, y es opinión: una lista larga no dice que el código haya empeorado, dice que alguien por fin ha mirado. Que un fabricante monte un equipo interno para buscarse los fallos a sí mismo y publique con su nombre lo que encuentra es de las pocas cosas francamente buenas de este boletín. Conviene no confundir los papeles, eso sí: quien firma el hallazgo no escribe el titular del aviso. El titular sale del proceso de publicación del fabricante, y es ahí donde se pierde la palabra «potencial» y donde un fallo que necesita credenciales acaba anunciado como si no las necesitara.

Y aun así: una sola actualización cierra los diez

Toca desinflar el artículo, porque si no sería deshonesto. Nada de esta lectura cambia lo que hay que hacer: subir a 2026.2.2, a 12.12.2 o a 12.5.20 según la rama, y ya está, los diez cerrados de una vez. Leer las diez fichas cuesta unos cuarenta minutos y no ahorra ni un reinicio.

Lo que decide es cuándo, y qué cuentas mientras tanto. Si la lectura te dice que seis los alcanza cualquiera desde internet, la ventana es esta semana y se justifica sola. Si te dijera —que no es el caso aquí— que los serios necesitan credenciales o consola, la ventana es la del mes que viene y también se justifica. La diferencia entre las dos decisiones son cuarenta minutos de lectura, y lo caro no es equivocarse hacia arriba: es la costumbre de tratar los diez boletines del mes por el titular hasta que uno de ellos importaba. De por qué esa ventana existe o no existe ya escribimos hace cinco días a cuenta de otro aparato de perímetro, y no lo vamos a repetir aquí.

Cómo leemos un boletín así

  1. El campo de impacto antes que el título. El título es la clase del fallo; el impacto es lo que pasa y lo que hace falta para que pase. Cuando los dos no coinciden, manda el impacto, y anótalo: acabas de aprender algo sobre cómo publica ese fabricante.
  2. Subraya los verbos débiles. «Podría», «potencial», «si es explotable», «en condiciones favorables». No son relleno legal: son el margen entre lo demostrado y lo temido, y es el margen del que sale tu decisión.
  3. Ordena por lo que queda después, no por la puntuación. La lista ordenada por consecuencia rara vez coincide con la ordenada por CVSS, y la que decide tu noche es la primera.
  4. Cruza cada condición previa con tu configuración real, no con la que recuerdas. «Requiere el registro de diagnóstico encendido» es una pregunta con respuesta comprobable esta tarde, y la respuesta dice más de tu operación que del CVE.
  5. Escribe la frase que vas a decir en voz alta antes de decirla. Si no puedes sostenerla señalando el párrafo del que sale, no es tuya todavía.

Y un apunte que ordena el resto: no todo boletín merece cuarenta minutos. Este los merecía por dónde estaba —el proceso que atiende antes de autenticar— y por el tamaño. La otra cara la contamos hace tres días al contar el catálogo de vulnerabilidades explotadas de CISA: lo que acaba usándose contra alguien casi nunca es exótico. Del Firebox de este mismo fabricante ya salieron dos así en dos meses: el CVE-2025-9242, añadido al catálogo el 12 de noviembre de 2025 con plazo el 3 de diciembre, y el CVE-2025-14733, añadido el 19 de diciembre con plazo el 26. Los dos, escritura fuera de límites. Cuando eso pasa, no hay boletín que leer: hay que parchear.

¿Quién lee estos boletines en tu empresa?

Diseñamos y operamos redes y comunicaciones multisede, y la parte aburrida va incluida: los avisos del fabricante llegan a alguien, se leen enteros y se traducen a una fecha de ventana o a un «esto puede esperar», por escrito. Cuando lo que hace falta es además vigilar lo que pasa en el perímetro entre ventana y ventana, eso es ciberseguridad gestionada. Si hoy nadie tiene ese correo asignado, empieza por ahí: es gratis y es el arreglo más rentable de la lista.

Hablar con everyWAN

Nota de fuentes

El recuento de avisos del 27 de agosto de 2026 y su reparto entre Dimension y Fireware OS salen del índice público del PSIRT de WatchGuard. Los títulos, las puntuaciones CVSS v4, los campos de impacto citados, las condiciones previas, los créditos y las versiones corregidas son de las diez fichas individuales: 19313, 19314, 19315, 19316, 19317, 19318, 78009, 78010, 78011 y 81851. Las citas en inglés se reproducen literalmente y el texto explica en cada caso qué dicen. Las dos entradas de Firebox en el catálogo de vulnerabilidades explotadas de CISA —CVE-2025-9242, añadida el 12-11-2025 con plazo el 03-12-2025, y CVE-2025-14733, añadida el 19-12-2025 con plazo el 26-12-2025, ambas descritas como escritura fuera de límites— salen del JSON público del propio catálogo; Security Affairs cubrió la segunda. El recuento de la tabla —seis alcanzables sin nada, uno con el diagnóstico encendido, uno con credenciales de VPN, uno con sesión de administrador y uno no reproducido— es nuestro, hecho leyendo los diez campos de impacto; cualquiera puede rehacerlo con los enlaces de arriba y llegar a otro reparto si interpreta distinto alguna ficha. Las opiniones son nuestras: que el titular describe la clase y el impacto la decisión, que perder la palabra «potencial» cambia la conversación con dirección, que el CVE-2026-78009 es el que miraríamos primero pese a su 8,7, que una lista larga indica que alguien ha auditado y no que el código haya empeorado, y que publicar un fallo que no se ha conseguido reproducir es lo correcto, salen de diseñar y operar redes multisede, no de las fuentes citadas.

Redes Ciberseguridad VPN Parcheo
Compartir

Suscríbete a nuestra newsletter

Para recibir historias del mundo IT, novedades de everyWAN y ofertas exclusivas para suscriptores, date de alta a nuestra lista de correo

everyWAN
everyWAN