El 18 de agosto CISA añadió el CVE-2026-33824 a su catálogo de vulnerabilidades explotadas. Microsoft lo había parcheado el 14 de abril, con una etiqueta al lado: Exploitation Less Likely. Esta mañana, dos días después de que CISA dijera lo contrario, esa ficha sigue diciendo lo mismo que en abril.
El fallo, en dos párrafos
La ficha oficial se titula «Windows Internet Key Exchange (IKE) Service Extensions Remote Code Execution Vulnerability» y la descripción cabe en una línea: «Double free in Windows IKE Extension allows an unauthorized attacker to execute code over a network». CVSS 9,8. CWE-415. La pregunta del FAQ de Microsoft la responde el propio Microsoft: «An unauthenticated attacker could send specially crafted packets to a Windows machine with Internet Key Exchange (IKE) version 2 enabled, which could enable remote code execution». Los puertos son UDP 500 y 4500, los de siempre de IPsec.
El detalle técnico lo publicó la Zero Day Initiative el 23 de abril, firmado por Richard Chen y Lucas Miller: al reensamblar un mensaje IKE_AUTH fragmentado, un puntero a un blob de Security Realm —que el propio atacante ha hecho reservar en el IKE_SA_INIT previo— se copia de forma superficial desde la estructura MMSA a un elemento de trabajo del montículo, y acaba liberándose dos veces, una en IkeDestroyPacketContext y otra en IkeFreeMMSA. El resultado, en sus palabras: «Successful exploitation could result in a crash of the IKEEXT service, or potentially arbitrary code execution», y el servicio se ejecuta como SYSTEM.
Conviene quedarse con dónde ocurre: en el reensamblado del paquete. Antes de que nadie haya demostrado ser nadie. Si tu VPN pide segundo factor, el segundo factor vive detrás de un intercambio que el atacante no necesita terminar. Lo mismo para los certificados de máquina y para las claves precompartidas. No es que la autenticación falle: es que el fallo está delante de ella.
La etiqueta
El índice de explotabilidad de Microsoft tiene cuatro peldaños. El que le tocó a este CVE, Exploitation Less Likely, está definido así en la web del MSRC: «[w]hile exploit code could be created, an attacker would likely have difficulty creating the code, requiring expertise and/or sophisticated timing, and/or varied results when targeting the affected product». El vector temporal que acompaña a la ficha lo dice en taquigrafía: E:U, exploit no probado.
Esa etiqueta no pretende ser eterna, y Microsoft lo dice sin rodeos: el índice existe para «help customers prioritize those updates for the most current monthly release», y las valoraciones pueden revisarse durante el primer mes, pero no después, porque a partir de ahí «it is no longer useful to the customer». Es una posición defendible para un fabricante. El problema aparece en la otra punta: la ficha se queda congelada, el inventario de parches de medio mundo la lee por API, y una foto de abril se convierte en un veredicto permanente.
Fuimos a contarlo
Nos picó la curiosidad, así que lo miramos entero esta mañana. Cruzamos el catálogo KEV de CISA con la API del Security Update Guide de Microsoft. En lo que va de 2026, CISA ha añadido 35 entradas de Microsoft; nos quedamos con las 24 que corresponden a CVE de 2025 y 2026 —las demás son fallos de 2012 o anteriores, más tres de 2023 y 2024 que dejamos fuera para no mezclar cosechas—. De esas 24:
| Etiqueta el día del parche | Cuántos | Días hasta entrar en KEV |
|---|---|---|
| Exploitation Detected | 17 | mediana 0; dieciséis de diecisiete, en dos días o menos |
| Exploitation More Likely | 3 | 8, 8, 35 |
| Exploitation Less Likely | 4 | 41, 64, 126, 153 |
El 126 es el nuestro. El 153 es el CVE-2025-60710, publicado el 11 de noviembre de 2025 y añadido a KEV el 13 de abril de 2026. Y hay cuatro CVE en esa lista con CVSS de 9 para arriba que el día del parche no estaban marcados como explotados; tres de ellos, con un 9,8 en la ficha.
Antes de sacar conclusiones grandes, el matiz que este dato exige: es un numerador sin denominador. No sabemos cuántos CVE etiquetados Less Likely publicó Microsoft en el mismo periodo y jamás se explotaron, y son la inmensa mayoría. La tabla no dice «la etiqueta se equivoca mucho». Dice otra cosa, más incómoda y más útil: cuando la etiqueta acierta, no te da margen —mediana de cero días entre el parche y KEV, porque Microsoft ya sabía que estaba pasando cuando publicó— y cuando te da margen es porque no sabía nada. Como información es válida. Como orden de cola, no ordena nada.
Los 126 días, con fechas
| Fecha | Qué pasó |
|---|---|
| 14 abr | Microsoft publica el parche. Crítica, 9,8, «Exploitation Less Likely», «Exploited: No». |
| 23 abr | La Zero Day Initiative publica el análisis del double free, con nombres de función. |
| sin fecha | Unit 42 documenta la explotación, sin datarla: en su lista de campañas manuales, «Reverse shell callbacks targeting three IKE VPN endpoints (CVE-2026-33824)». |
| 30 jul | Unit 42 publica la campaña completa: más de 460 objetivos, un actor de habla china, y un agente de IA orquestando buena parte del trabajo. |
| 18 ago | CISA lo mete en KEV, con fecha límite el 21 para la administración federal estadounidense. |
| 20 ago | Consultamos la ficha del MSRC: última revisión, 14 de abril. Sigue poniendo «Exploitation Less Likely». |
El titular de la campaña de Unit 42 es el agente de IA, y se entiende: da para portada. Pero si uno baja a la línea de este CVE en concreto, el informe lo coloca en el apartado de campañas manuales: enumeración con FOFA, escáneres en Python y explotación a mano. Para esto bastó con un parche de semanas atrás sin aplicar.
Las dos mitigaciones, y la que no puedes aplicar
Microsoft ofrece dos salidas a quien no pueda instalar la actualización: «Block inbound traffic on UDP ports 500 and 4500 for systems that do not use IKE» y «For systems that require IKE, configure firewall rules to allow inbound traffic on UDP ports 500 and 4500 only from known peer addresses». Y añade, con razón, que ninguna de las dos sustituye al parche.
La primera es limpia y hay que aplicarla ya: si un servidor no termina túneles, esos dos puertos no tienen por qué estar abiertos a Internet. La segunda funciona muy bien en los túneles entre sedes, donde el otro extremo es una IP fija que conoces. Y deja fuera justo el caso que a una pyme le duele: el acceso remoto. Un comercial que se conecta desde el 4G de un hotel no tiene «known peer address». Esa lista blanca no se puede escribir. Es una lectura nuestra, no una cita de nadie, pero no le vemos la vuelta: si publicas acceso remoto IKEv2 a Internet, tu mitigación es el parche de abril y no hay otra.
Con una excepción: si tus usuarios entran siempre desde cuatro sedes conocidas, la lista blanca sí vale y vale mucho. El teletrabajo de verdad, el de las IP domésticas que cambian, es el que se queda sin red.
Media hora, en este orden
- Quién escucha. En cada Windows expuesto:
Get-NetUDPEndpoint -LocalPort 500,4500 | Select-Object LocalAddress, LocalPort, OwningProcessyGet-Service IKEEXT. El servicio está en todas las versiones soportadas; lo que hay que averiguar es si además tiene algo escuchando. - Desde fuera. Un
nmap -sU -p 500,4500contra tus IP públicas, sabiendo que el escaneo UDP miente por naturaleza: «no hay respuesta» no significa «cerrado». Si sale abierto, es que sí. - El parche. Es acumulativo: cualquier acumulativo del 14 de abril de 2026 o posterior lo lleva. Mira la fecha del último que instalaste; si es anterior, ya lo sabes. La ficha del MSRC lista el KB que toca a cada versión.
- Lo que sobra. Cada puerto 500 y 4500 abierto a un servidor que no termina túneles se cierra hoy y no se discute.
- Si tienes con qué mirar el tráfico, la ZDI publica la única regla de detección que hemos visto para esto, y no es trivial porque hace falta correlacionar dos paquetes: «Detection requires correlating two packets within the same IKE session: an IKE_SA_INIT request carrying the Microsoft Security Realm Vendor ID, followed by a fragmented IKE_AUTH request. Neither packet alone is malicious; both must be observed in sequence from the same source». Ninguno de los dos, por separado, va a levantar una alerta.
Y una pregunta de arquitectura para después de la urgencia, que es donde de verdad se gana: si tu concentrador de VPN es un servidor Windows del dominio publicado a Internet, cada fallo de este tipo te cuesta un domingo. Sobre elegir túnel escribimos una comparativa entre WireGuard e IPsec, y sobre lo que pasa cuando el que falla es el propio equipo del perímetro, los zero-days de SonicWall SMA 1000.
Cuándo no correríamos
Declaramos el conflicto de interés de entrada: vendemos servicios gestionados de red y de seguridad, y un texto así nos conviene. Con eso sobre la mesa: si tus Windows no publican 500 ni 4500 a Internet, esto no es una emergencia. Es un parche de la ventana normal, del próximo mantenimiento programado, sin sacar a nadie de vacaciones. El plazo del 21 de agosto es una obligación de las agencias federales estadounidenses, no una fecha con la que medirte —de eso ya escribimos hace unos días—. Reinstalar el concentrador entero en agosto porque un titular da miedo suele salir peor que aplicar un acumulativo.
Lo que se queda
El fallo se arregló en abril. Lo que no se ha arreglado es el renglón que lo describe, y ese renglón es el que muchos equipos usan para decidir qué se parchea el martes y qué espera al trimestre. Un CVSS de 9,8 y un «menos probable» en la misma pantalla no son dos datos: son dos consejos contrarios, y el segundo tiene la ventaja de sonar tranquilizador.
La pregunta que queda es más sencilla y va de tu cola: de los parches que tienes ahora mismo aparcados, ¿cuántos lo están porque alguien —una consola, un informe, un renglón heredado— dijo que era poco probable?
Fuentes (verificadas el 20 de agosto de 2026): el título oficial del CVE, la fecha de publicación del 14 de abril de 2026, la severidad crítica, el CVSS 9,8, el vector con E:U, la etiqueta «Exploitation Less Likely», el «Exploited: No», la fecha de última revisión y las frases del FAQ y de las mitigaciones citadas literalmente, de la ficha del CVE-2026-33824 en el Security Update Guide de Microsoft, consultada a través de su API el 20 de agosto a las 08:05. Las definiciones del índice de explotabilidad y la política de no revisarlo pasado el primer mes, de la página del Exploitability Index del MSRC. La fecha de alta en el catálogo (18 de agosto), el plazo del 21 y la descripción, del catálogo KEV de CISA, versión 2026.08.19. El análisis del double free, los nombres de función, la regla de detección de los dos paquetes correlacionados y la frase «Successful exploitation could result in a crash of the IKEEXT service, or potentially arbitrary code execution», del análisis de la Zero Day Initiative firmado por Richard Chen y Lucas Miller. La frase «Reverse shell callbacks targeting three IKE VPN endpoints (CVE-2026-33824)», los más de 460 objetivos y el uso de FOFA y escáneres en Python para este caso concreto, del informe de Unit 42 del 30 de julio de 2026. Es nuestro el recuento de las 35 entradas de Microsoft en KEV en 2026 y de las 24 de 2025 y 2026, con sus etiquetas y sus días hasta KEV, hecho cruzando ambas fuentes esta mañana; es nuestra también la lectura de que la lista blanca de «known peer addresses» no se puede escribir para acceso remoto, y se declara como lectura en el texto. Las citas de Microsoft, de la ZDI y de Unit 42 se dejan en inglés, su idioma original, para que se puedan verificar palabra por palabra.
¿Sabes qué escucha hoy en tus IP públicas?
Montamos y mantenemos el acceso remoto y los túneles entre sedes de nuestros clientes: redes y comunicaciones con la lista de lo que está publicado encima de la mesa, no en la cabeza de nadie. Y cuando lo que toca es decidir en qué orden se parchea, lo miramos como servicio de ciberseguridad, empezando por la exposición: qué hay publicado y en qué puerto.
Hablar con everyWAN