Red Hat publicó kernels corregidos para Red Hat Enterprise Linux (RHEL) 8, 9 y 10 contra CVE-2026-98432, una falla en el código TCP IPv4 del kernel Linux con puntaje de 9,8 sobre 10. Ubuntu solo tiene sus correcciones en un canal de pruebas opcional y no ha fijado fecha de publicación general. La falla permite que un atacante remoto, sin credenciales, comprometa servidores Linux con cualquier puerto TCP a la escucha.
El error es de tipo uso después de liberar (use-after-free): el kernel lee una zona de memoria que ya había liberado. Cuando un servidor acepta una conexión TCP IPv4, el kernel pasa las opciones IP de la solicitud al nuevo socket sin copiarlas. Si el cliente retransmite su solicitud mientras otro procesador lee esas opciones, se produce la lectura indebida. El atacante provoca esta condición de carrera (dos procesos compiten por el mismo dato) enviando solicitudes con las opciones IPv4 Record Route o Timestamp. IPv6 no está afectado en la ruta principal. El fallo existe desde Linux 4.4 y la corrección oficial del kernel llegó en octubre.
Red Hat calificó la falla al inicio como moderada (5,9), pero luego la elevó a crítica (9,8). Amazon Linux la puntuó en 8,1 y considera que el efecto principal es una caída del sistema con posible corrupción de memoria. Ningún fabricante ni CERT ha reportado ataques reales, y la falla no figuraba en el catálogo KEV de CISA al 30 de octubre. Sin embargo, Anthropic informó que un modelo interno de investigación escribió un exploit funcional para obtener acceso root remoto. Ese exploit funciona contra servidores con un servicio MPTCP activo (Multipath TCP, extensión que usa varias rutas de red en una misma conexión). En la prueba de concepto, filtrar una dirección del kernel tomó 48 minutos y obtener una consola root, 5 minutos más. El código no se ha publicado. En GitHub circula un código que solo dispara la condición de carrera, sin ejecutar código.
Red Hat liberó las correcciones el 1 de noviembre; requieren reinicio. Las versiones corregidas son: RHEL 8.10 con kernel 4.18.0-553.182.1.el8_10 (RHSA-2026:93414), RHEL 9.8 con 5.14.0-687.64.1.el9_8 (RHSA-2026:93412) y RHEL 10.2 con 6.12.0-211.72.1.el10_2 (RHSA-2026:93413). En Ubuntu, los kernels corregidos están en el canal -proposed: 5.15.0-203.213 para 22.04 LTS, 6.8.0-149.149 para 24.04 LTS y 7.0.0-43.43 para 26.04 LTS. Ese canal no instala paquetes de forma automática; el administrador debe habilitarlo. Ubuntu 20.04, 18.04 y 16.04 aún no tienen corrección, y las variantes de kernel para nube, FIPS y tiempo real siguen en desarrollo. Debian, Oracle Linux y SUSE publicaron parches en octubre, y Amazon Linux quedó corregido entre el 24 y el 30 de octubre. Para verificar un servidor, compare la salida de uname -r con estas versiones.
Como medida temporal, Red Hat publicó una regla de nftables que descarta paquetes TCP IPv4 entrantes con opciones IP: ip protocol tcp ip hdrlength > 5 counter drop. La regla bloquea el disparador conocido, pero no impide del todo la explotación y puede afectar aplicaciones que dependan de esas opciones. Además, solo protege al equipo donde se carga: el tráfico entre contenedores del mismo servidor puede evadirla. Deshabilitar MPTCP, como han sugerido algunas fuentes, no basta. Canonical es tajante: las actualizaciones de seguridad son la única mitigación adecuada.
Qué significa para tu empresa: esta semana conviene inventariar los servidores Linux expuestos a internet y priorizar los RHEL y distribuciones que ya tienen parche, con su ventana de reinicio. Para los equipos Ubuntu sin corrección estable, defina si prueba el kernel de -proposed o aplica controles compensatorios. Un firewall perimetral NGFW, como FortiGate, puede descartar en el borde los paquetes IPv4 con opciones IP y reducir la exposición mientras llega el parche. Ese control no reemplaza la actualización ni protege el tráfico interno entre contenedores.
Fuente original: The Hacker News — ver artículo →