Fallo TCP en el kernel de Linux (CVE-2026-98432): qué distribuciones tienen parche y cómo actuar sin él

El fallo TCP del kernel de Linux CVE-2026-98432 recibe un 9,8 sobre 10 del equipo CVE del propio kernel, según The Hacker News y Cyberkendra [1][2], mientras que Red Hat, Amazon, Oracle y SUSE lo valoran por debajo, según The Hacker News [1]. A 29 de octubre de 2026, además, Ubuntu y Red Hat Enterprise Linux (RHEL) seguían sin publicar un kernel corregido [1].

Si administras servidores, la pregunta útil no es qué nota acierta. Lo que importa es qué equipos están en juego y qué haces con ellos hoy. La respuesta pasa por una función concreta del kernel, el multipath TCP (MPTCP), y por un plan que no depende de que llegue el parche.

El fallo es una condición de carrera en el arranque de conexiones TCP

Según The Hacker News, el problema está en la parte del kernel que establece las conexiones TCP nuevas sobre IPv4. Se trata de una condición de carrera durante el saludo inicial de la conexión TCP [1]. Al completarse el saludo inicial de la conexión (handshake), el kernel entrega al nuevo socket las opciones IP de la solicitud pendiente sin copiarlas. Si ese socket se destruye mientras otro procesador sigue usando esas opciones para responder a una solicitud reenviada, el kernel acaba leyendo memoria que ya había liberado [1].

Ese tipo de error se conoce como use-after-free: el sistema sigue usando una zona de memoria que ya había dado por libre. Según la misma fuente, IPv6 no se ve afectado por esta carrera, porque en ese caso el kernel sí copia las opciones [1].

El alcance es amplio. Cyberkendra indica, citando el registro CVE, que el fallo está presente desde Linux 4.4, por lo que llega a casi todos los kernels de distribución que siguen mantenidos [2]. La excepción, según Red Hat recogida por esa misma fuente, es RHEL 7, cuyo kernel nunca recibió el código vulnerable [2]. Los desarrolladores del kernel aplicaron la corrección el 5 de octubre, antes de que se publicara el CVE, según The Hacker News [1].

Un exploit remoto como root convierte el MPTCP en el criterio de prioridad

Lo que ha convertido este fallo en urgente es una publicación de Anthropic. Según The Hacker News, la empresa explicó el 27 de octubre que su modelo de IA, Claude, había escrito un exploit con el que un atacante remoto y sin credenciales ejecuta comandos como root en servidores Linux que tienen un listener de multipath TCP [1]. Cyberkendra lo describe como un exploit remoto que no requiere interacción del usuario [2]. La publicación de Anthropic no incluye el código del exploit, la versión del kernel probada ni la configuración usada [1].

El MPTCP permite que una misma conexión use varias rutas de red a la vez, y en Linux una aplicación tiene que pedirlo expresamente al abrir el socket, según The Hacker News [1]. Eso lo convierte en un buen primer filtro: no está presente por defecto en cualquier servicio, y averiguar qué aplicaciones lo usan es una tarea acotada.

Conviene, eso sí, no ir más allá de lo que dicen las fuentes. Ni el registro CVE ni la corrección del kernel mencionan MPTCP; esa relación procede solo de la publicación de Anthropic [1]. Red Hat, por su parte, indica que un atacante remoto que alcance un servicio TCP expuesto podría provocar la carrera, y Anthropic no aclara si los servidores sin MPTCP pueden comprometerse de la misma forma [1]. El MPTCP marca dónde empezar, no dónde terminar.

Tampoco hay constancia de ataques reales. Según The Hacker News, a 29 de octubre ningún aviso de fabricante, ni el registro CVE ni la publicación de Anthropic informaban de explotación, y el fallo no figuraba en la copia del catálogo de vulnerabilidades explotadas conocidas de CISA que el CIRCL de Luxemburgo actualizó el 28 de octubre [1]. Cyberkendra añade que un grupo de investigación llamado Innora ha publicado un análisis de la causa raíz y un entorno de reproducción, aunque afirma que no difundirá un exploit operativo a corto plazo [2].

Entre la nota más baja y el 9,8 la decisión práctica es la misma

La disparidad de valoraciones tiene una explicación técnica concreta. Según The Hacker News, el equipo CVE del kernel añadió el 9,8 al registro el 24 de octubre, suponiendo un atacante que envía una solicitud de conexión con las opciones IPv4 Record Route o Timestamp y la reenvía para intentar ganar la carrera; por eso considera baja la complejidad del ataque [1]. Oracle y SUSE coinciden con el equipo del kernel en casi todo, salvo precisamente en esa complejidad, que valoran como alta [1].

Red Hat ha mostrado incluso dos lecturas a la vez. Su página del CVE califica el fallo de moderado, porque la carrera es difícil de ganar y el resultado más probable sería un cierre inesperado del kernel, mientras que su fichero de aviso legible por máquina, actualizado el 29 de octubre, lo elevó a importante, según The Hacker News [1]. Cyberkendra precisa que no pudo confirmar ese cambio de forma independiente [2].

La lectura razonable es que cada organización puntúa un escenario distinto, y ninguno de esos escenarios es tu configuración. Una nota baja que asume una carrera difícil de ganar pierde peso cuando existe un exploit descrito como funcional. Según The Hacker News, Anthropic explica además que una carrera perdida solo hace fallar ese intento de conexión, sin tumbar el sistema, de modo que el atacante puede seguir probando [1]. Con ese dato, incluso la valoración más baja justifica actuar sobre los equipos expuestos.

A 29 de octubre, Ubuntu y RHEL siguen sin kernel corregido

Según la publicación de Anthropic citada por The Hacker News, la corrección ya está en el código principal del kernel y en todas sus ramas estables mantenidas, pero quien usa una distribución solo la recibe cuando el proveedor publica su propio paquete de kernel [1]. El estado conocido a 29 de octubre era este, según The Hacker News y Cyberkendra [1][2]:

• Ubuntu: sin kernel corregido. Todas las versiones soportadas figuran como vulnerables o con la corrección en curso, incluidos los kernels para la nube, FIPS y de tiempo real.
• RHEL 8, 9 y 10 y OpenShift 4: corrección aplazada a una actualización futura.
• RHEL 7: no afectado.
• Debian: paquetes corregidos para trixie y Debian 12 (bookworm).
• Oracle Linux con kernel UEK: corregido desde el 16 de octubre.
• Amazon Linux: corregidos algunos kernels de Amazon Linux 2023; Amazon Linux 2 y el kernel por defecto de Amazon Linux 2023, pendientes.
• SUSE: corregido en SUSE Linux Micro 6.2 y openSUSE Leap 16.0; varias versiones de SLES, en pruebas o en curso.

Ni Red Hat ni Ubuntu daban fecha de publicación [1]. Cyberkendra señala que el sistema de seguimiento de Ubuntu muestra versiones corregidas en preparación [2]. Esta lista es una foto con fecha de corte y probablemente habrá cambiado cuando la leas: el aviso oficial de cada proveedor manda. En el caso de Ubuntu, Canonical publica sus correcciones de kernel en la lista ubuntu-security-announce, incluidos parches en vivo (livepatch) para sus kernels LTS [3], así que conviene vigilarla.

Sin parche, el plan se basa en inventario, exposición y vigilancia

Donde ya exista un kernel corregido, la indicación de las fuentes es instalarlo y reiniciar, porque la actualización solo surte efecto cuando el kernel nuevo está en marcha; Cyberkendra recuerda que uname -r muestra la versión activa para compararla con el aviso del fabricante [2].

El problema está en el resto. Según The Hacker News, Red Hat afirma que ninguna mitigación disponible cumple sus criterios de ser fácil de desplegar, apta para la mayoría de instalaciones y estable, y ningún otro aviso propone una [1]. Las fuentes tampoco aclaran si desactivar MPTCP o bloquear las solicitudes de conexión con opciones IP reduciría el riesgo [1]. Por eso no conviene improvisar cambios de configuración en producción. Lo que sí puedes hacer es ordenar el trabajo:

1. Inventariar qué servidores Linux tienen un listener MPTCP, con su distribución y versión de kernel.
2. Priorizar los que son accesibles desde redes no confiables y, después, el resto de servicios TCP expuestos.
3. Consultar los avisos de Canonical y Red Hat para aplicar la mitigación oficial en cuanto la publiquen.
4. Reforzar la vigilancia de esos equipos hasta que haya kernel corregido.
5. Programar el reinicio con el kernel nuevo en cuanto exista.

Cualquier medida técnica concreta debe confirmarse con el aviso del fabricante. Mientras tanto, la vigilancia deja de ser un complemento y pasa a ser la defensa principal; si tu equipo no tiene capacidad para hacerla de forma continua, una monitorización y respuesta gestionada de los servidores expuestos puede cubrir ese hueco temporal.

En pymes y entornos industriales el reto es saber dónde hay Linux

Al revisar el inventario, conviene comprobar si hay Linux en servidores de aplicaciones, pasarelas, equipos de acceso remoto o máquinas auxiliares entre la red de TI y la de planta. Conviene identificar dónde aplicar el parche y planificar una ventana de reinicio que tenga en cuenta la continuidad de la producción.

Aquí el MPTCP vuelve a ser útil, porque permite acotar el alcance. No hay que suponer que un producto industrial está afectado; lo práctico es comprobar qué equipos de tu red usan esa función o exponen servicios TCP a redes no confiables, y planificar con tiempo el reinicio de los que no pueden detenerse de inmediato. Revisar esas dependencias entre TI y planta forma parte de la seguridad OT industrial, y conviene tenerlo hecho antes del próximo aviso.

Una vulnerabilidad con exploit descrito públicamente pide actuar por exposición, no por nota

El debate entre el 9,8 del equipo del kernel y las valoraciones más bajas de los fabricantes es un dato de contexto. Lo que decide la urgencia es si un servidor tiene un listener MPTCP o servicios TCP accesibles desde redes no confiables, y eso se puede comprobar hoy, sin esperar a que Ubuntu y RHEL publiquen el kernel corregido.

Para una pyme industrial o de TI, el trabajo útil es el mismo que sirve para la siguiente vulnerabilidad: inventario al día, exposición mínima, vigilancia y ventanas de reinicio previstas. Si quieres ordenar ese punto de partida, la guía básica de ciberseguridad para pymes es un buen lugar para empezar.