Una vulnerabilidad crítica en el kernel de Linux, identificada como CVE-2026-98432, fue corregida con un parche de apenas cuatro líneas, pero las distribuciones más usadas en servidores, Ubuntu y Red Hat Enterprise Linux (RHEL), aún no han liberado sus kernels actualizados, dejando a miles de sistemas expuestos a un ataque remoto sin autenticación.
El fallo, un use-after-free en el código que procesa el saludo TCP sobre IPv4, permite a un atacante remoto leer memoria del kernel, corromperla o tumbar el servidor simplemente enviando paquetes de conexión. Lo más preocupante: Anthropic reveló que su modelo de inteligencia artificial Claude escribió un exploit funcional que otorga acceso root remoto sin necesidad de credenciales.
¿Qué es exactamente CVE-2026-98432?
Se trata de un use-after-free (UAF) en el subsistema de red del kernel de Linux, específicamente en el manejo de opciones IPv4 durante el handshake TCP. El kernel libera la memoria que almacena las opciones IP de una solicitud de conexión y, debido a una condición de carrera, otra ruta del código puede acceder a ella después de liberada.
El parche definitivo, firmado por Eric Dumazet y revisado por Kuniyuki Iwashima, mantenedores del subsistema de red, mueve la liberación de memoria después del período de gracia de RCU (Read-Copy-Update), el mecanismo que garantiza que nadie más esté leyendo una estructura antes de borrarla.
La vulnerabilidad afecta a todas las versiones del kernel desde la 4.4 (lanzada en 2016) hasta las ramas estables corregidas. Las versiones 4.4 a 5.4 ya alcanzaron su fin de vida upstream y no recibirán parche oficial, por lo que las distribuciones que aún las mantienen deben portar la corrección por su cuenta.
Estado de las distribuciones: parche disponible pero no aplicado
El kernel estable de Linux publicó las versiones corregidas el 11 y 15 de octubre de 2026: 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 y 7.3. El registro en cve.org se realizó el 15 de octubre con una puntuación CVSS 3.1 de 9.8 sobre 10, la máxima para un fallo que no requiere interacción del usuario.
Red Hat elevó su calificación de Important (8.1) a Critical (9.8) el 30 de octubre y publicó un boletín con una mitigación temporal, pero hasta el 31 de octubre sus kernels para RHEL 8, 9 y 10, así como OpenShift Container Platform, seguían sin parche disponible. Ubuntu, por su parte, mantenía el paquete linux marcado como “Vulnerable” en todas sus versiones soportadas, sin aviso de seguridad publicado.
No todas las distribuciones van atrasadas. AlmaLinux ya tiene kernels corregidos en su repositorio de pruebas desde el 30 de octubre, un día antes que Red Hat, de quien deriva su base. Amazon Linux corrigió todos sus kernels, y Debian, SUSE Enterprise y Oracle UEK también cuentan con versiones parchadas desde antes de que Red Hat subiera la calificación.
Tabla de estado al 31 de octubre de 2026
- Ubuntu: Vulnerable en todas las versiones soportadas. Sin kernel corregido.
- Red Hat Enterprise Linux (8, 9, 10): Afectado, calificación subida a Critical. Sin kernel corregido.
- AlmaLinux (8, 9, 10): Kernel corregido en repositorio de pruebas desde el 30 de octubre (kernel-4.18.0-553.180.2.el8_10 y equivalentes).
- Amazon Linux: Todos los kernels corregidos. Disponible.
- Debian / SUSE Enterprise / Oracle UEK: Kernels corregidos. Disponible.
El exploit de Claude y el riesgo de Multipath TCP
La vulnerabilidad fue reportada por Xinyang Ge, investigador de Anthropic. Según la compañía, su modelo Claude escribió una prueba de concepto que explota la falla para obtener acceso root remoto sin credenciales. El exploit requiere que el servidor tenga un listener de Multipath TCP (MPTCP) activo, una extensión que combina varias rutas de red en una sola conexión.
El equipo de seguridad de Go advirtió que los programas escritos en ese lenguaje abren ese tipo de listener por defecto, por lo que la configuración necesaria para el ataque es más común de lo que se pensaba. No se requiere que un administrador haya activado MPTCP deliberadamente.
⚠️ Ojo: si tu servidor corre un binario de Go con un listener TCP, probablemente tenga Multipath TCP activado sin que lo hayas pedido. Revísalo antes de asumir que el ataque no te toca.
El impacto real alcanza a cualquier servidor físico o virtual con kernel 4.4 o posterior sin el parche, incluidos los contenedores: un contenedor comparte el kernel del host, así que una imagen nueva no cambia nada si la máquina subyacente sigue vulnerable. IPv6 no se ve afectado por este problema en particular, ya que su pila de red no comparte el mismo camino de opciones IP.
¿Qué hacer mientras llega el parche?
Lo primero es verificar el estado del kernel en tu distribución. Los números de versión no coinciden entre el kernel upstream y el empaquetado por cada distribución. Ejecuta uname -r y compara el resultado con la tabla de versiones corregidas: un kernel como 6.12.113-generic ya incluye el fix si el número es igual o posterior al listado.
En Ubuntu Pro, el comando pro fix CVE-2026-98432 --dry-run indica si el paquete instalado sigue expuesto.
Mientras llega el parche, Red Hat propone una mitigación con nftables en su boletín RHSB-2026-016, y Atlas sugiere una regla provisional: descartar los paquetes TCP que llevan opciones IPv4. Ambas opciones cortan también tráfico legítimo que use esas opciones, así que conviene aplicarlas solo temporalmente.
Si no usas Multipath TCP, desactivarlo reduce la superficie de ataque sin afectar el resto del tráfico; si lo usas, prioriza parchear esos hosts primero.
Un dato incómodo sobre la IA en seguridad
El episodio deja una señal preocupante: la misma falla crítica que un investigador humano reportó terminó con una prueba de concepto escrita por un modelo de lenguaje, capaz de convertir un bug remoto en acceso root sin usuario ni contraseña. Anthropic no publicó el exploit, pero que un modelo pueda llegar a ese resultado acorta el tiempo entre que se conoce un bug y que alguien lo convierte en un arma.
Para los equipos de desarrollo y operaciones en México y Latinoamérica, la recomendación es clara: revisar el rastreador de su distribución, aplicar las mitigaciones temporales si corren Ubuntu o RHEL, y considerar seriamente desactivar Multipath TCP si no es necesario. La ventana de exposición sigue abierta.