Microsoft corrigió CVE-2026-33824 el 14 de abril de 2026, dentro de su ciclo habitual de Patch Tuesday, como un fallo más de gravedad crítica en IKE Service Extensions. Lo que convierte este caso en algo distinto a un CVE crítico más es la cronología completa: Unit 42, de Palo Alto Networks, documentó el 30 de julio explotación activa manual de este mismo fallo por parte de un actor de habla china contra tres endpoints IKE VPN reales -- y CISA no lo añadió a su catálogo de vulnerabilidades explotadas conocidas (KEV) hasta el 18 de agosto, con un plazo de corrección federal de apenas tres días después.

Un doble free en el corazón del servicio VPN de Windows

El fallo vive en ikeext.dll, el componente que gestiona IKEv2 para conexiones VPN/IPsec. Según el análisis técnico de Zero Day Initiative, durante el reensamblado de fragmentos IKEv2 un bloque de memoria ("Security Realm") se copia de forma superficial a una estructura de trabajo, generando dos punteros vivos apuntando a la misma reserva de memoria. Dos funciones distintas del propio servicio (IkeDestroyPacketContext() e IkeFreeMMSA()) acaban liberando esa memoria dos veces -- un doble free clásico, aquí explotable para ejecutar código arbitrario con privilegios de SYSTEM. La secuencia de disparo es un mensaje IKE_SA_INIT manipulado con el Vendor ID de Microsoft Security Realm, seguido de un mensaje IKE_AUTH fragmentado con payloads inválidos -- sin necesidad de que exista ya un túnel VPN activo ni una política IPsec configurada, basta con que el servicio esté escuchando.

Cuatro meses entre el parche y la confirmación oficial de explotación activa es tiempo de sobra para que un sistema sin actualizar lleve ya semanas comprometido sin que nadie lo sepa

La cronología aquí es la inversa de lo deseable: parche en abril, explotación activa documentada por un tercero en julio, reconocimiento oficial de CISA en agosto. Para cualquier administrador que siga un ciclo de parcheo mensual disciplinado, esto no cambia nada -- ya está protegido desde la primavera. El problema real es para el parque de máquinas que quedó rezagado, por el motivo que sea, y que ahora se entera de golpe de que llevaba meses siendo un objetivo activo, no uno hipotético.

Exposición acotada, pero no trivial

Una matización importante: IKE/IPsec no viene activado por defecto en Windows. La superficie de ataque real se limita a los sistemas configurados explícitamente como servidor VPN de acceso remoto o con políticas IPsec activas -- no es "cualquier Windows conectado a internet". Dicho esto, es precisamente el tipo de servidor que un sysadmin de homelab o una pyme suele exponer a propósito a internet para que los usuarios remotos puedan conectarse, lo que convierte la exposición acotada en, aun así, relevante para buena parte de nuestros lectores.

Qué hacer si administras un servidor VPN de Windows

Si tu servidor aplica actualizaciones de Windows con regularidad desde abril, ya estás protegido -- confírmalo revisando el historial de actualizaciones en vez de darlo por hecho. Si no es el caso, la actualización de abril de 2026 o posterior es la prioridad inmediata. Mientras se aplica, Unit 42 y varios analistas recomiendan restringir el acceso entrante a UDP 500/4500 solo a IPs de pares VPN conocidas (en vez de abrirlo a cualquier origen), revisar los registros de eventos de VPN y perímetro en busca de anomalías, y, si el servicio IKEEXT no se usa realmente, desactivarlo por completo.

Para quién es urgente hoy mismo

Cualquier servidor Windows con rol de VPN/IPsec de acceso remoto expuesto a internet sin la actualización de abril de 2026 debería tratarse como potencialmente ya comprometido, dada la explotación activa documentada desde julio -- no como un riesgo a evaluar con calma. Para el resto -- sistemas sin IKE/IPsec configurado -- la exposición directa es baja, aunque conviene aplicar igualmente la actualización.