# MPTCP abre el CVE-2026-98432 y Linux sigue sin parche en RHEL > El exploit del CVE-2026-98432 apunta a los listeners MPTCP, que Go 1.24 abre por defecto. Debian ya parcheó, Ubuntu y RHEL siguen sin fecha cerrada. > Por José Maldonado · Ciberseguridad · 2026-11-02 La vulnerabilidad más comentada del mes en Linux tiene una puerta concreta y casi nadie la ha nombrado. El exploit que un modelo de investigación de Anthropic convirtió en shell de root remoto apunta a los listeners MPTCP, la extensión del protocolo de transporte que permite usar varias rutas de red a la vez. Y ahí aparece el detalle que cambia el cálculo de riesgo para miles de servicios en producción: desde Go 1.24, el runtime activa MPTCP por defecto en los sockets de escucha. El fallo, catalogado como CVE-2026-98432, es un use-after-free en el código TCP de IPv4. El equipo CVE del kernel lo puntuó con 9,8 sobre 10 el 24 de octubre, después de que el parche llegara a las ramas estables el 5 de octubre y de que la ficha pública se publicara el 15. Afecta a kernels desde la versión 4.4, lo que significa que el error lleva once años dentro del código sin que una auditoría humana lo encontrara. La ficha completa del fallo, con versiones afectadas y estado por distribución, está en [el seguimiento que publicamos el 31 de octubre](https://observatorioblockchain.com/ciberseguridad/cve-2026-98432-kernel-tcp-ubuntu-rhel-sin-parche/). El estado de parcheo sigue siendo desigual tres semanas después del hallazgo. Debian publicó el 16 de octubre la actualización DSA-6568-1 con linux 6.12.113-1 para Trixie y las versiones 6.1.190-1 y 6.12.113-1~deb12u1 para Bookworm. SUSE, Oracle y Amazon Linux corrigieron en sus ramas soportadas. Ubuntu tiene los kernels en preparación y Red Hat no ha comprometido fecha para RHEL 8, 9 ni 10. ## ¿Qué es MPTCP y por qué cambia el riesgo real? MPTCP permite que una conexión TCP use varias interfaces de red al mismo tiempo, de modo que si una ruta falla el tráfico continúa por otra. En móviles y en despliegues con enlaces redundantes es una ventaja evidente. En servidores Linux se ha usado poco porque añade complejidad al seguimiento de conexiones y porque la mayoría de aplicaciones no lo necesitan. El problema es que el código de MPTCP comparte estructuras con el handshake de TCP normal, y el use-after-free se dispara durante ese handshake. Un listener que acepta conexiones MPTCP expone una superficie más ancha que un listener TCP clásico, con más estados intermedios que liberar. La consecuencia práctica es que el exploit tiene donde apoyarse en servicios que hasta ahora se consideraban poco expuestos. Ahí entra Go. Desde la versión 1.24, la biblioteca estándar habilita MPTCP en los sockets de escucha cuando el kernel lo soporta, sin que el desarrollador tenga que pedirlo. Un servicio escrito en Go y desplegado en un kernel vulnerable puede estar aceptando conexiones por una vía que su equipo de operaciones no sabía que estaba abierta. La corrección del kernel llega con una asimetría curiosa. En Red Hat Enterprise Linux 8, 9 y 10, MPTCP viene desactivado por defecto, lo que reduce la exposición aunque no elimina el fallo. En Ubuntu la situación es distinta porque el soporte está más extendido. Esa diferencia explica por qué el mismo CVE tiene valoraciones tan dispares. ## La discrepancia de severidad que nadie explica Red Hat, Amazon, Oracle y SUSE sitúan el fallo entre 5,9 y 8,1, mientras el equipo CVE del kernel mantiene un 9,8. La distancia no es un capricho. Cada proveedor puntúa según su configuración por defecto y su modelo de amenaza, no según el peor escenario teórico. Un 5,9 sugiere que hace falta una condición poco común para explotarlo. Un 9,8 indica que cualquiera con acceso de red puede intentarlo sin credenciales. Las dos cifras pueden ser correctas al mismo tiempo y esa es justo la trampa: los equipos que priorizan por número aplazan parches que su propio despliegue sí necesita. Para un administrador de sistemas la lectura útil es otra. La pregunta no es qué nota tiene el CVE, sino si su kernel compila MPTCP, si hay listeners en Go y si el servicio está expuesto a Internet. Si no tienes claro por dónde empezar, [la guía para leer un CVE en diez minutos](https://observatorioblockchain.com/ciberseguridad/como-leer-un-cve-si-te-afecta/) ordena las mismas comprobaciones sin jerga. Tres comprobaciones concretas que valen más que cualquier escala. ## ¿Cómo saber si estás expuesto en tres comandos? La primera comprobación es la versión del kernel y la rama estable. Si el sistema corre 6.12.113, 6.18.56, 7.2.10 o 7.3-rc7 o posterior, el fallo está corregido. Las versiones afectadas llegan hasta 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.112, 6.18.55 y 7.2.9 según el inventario publicado por el centro nacional de ciberseguridad de Hungría. La segunda es si MPTCP está activo. El parámetro del sistema `net.mptcp.enabled` muestra el estado en caliente, y la orden `ss -M` lista los sockets que están usando esa pila. Un sistema con MPTCP desactivado no queda inmune, porque el fallo vive en código compartido, pero reduce la vía de entrada que el exploit aprovecha. La tercera es revisar qué servicios escuchan y en qué lenguaje están escritos. Un binario compilado con Go 1.24 o superior en un kernel vulnerable es la combinación que conviene parchear primero, sobre todo si atiende tráfico público. El resto puede esperar la ventana de mantenimiento habitual sin drama, siempre que haya compensaciones de red por delante. ## El parche sin reinicio y sus límites Para los entornos donde no se puede reiniciar, el proveedor TuxCare publicó el 29 de octubre un parche de kernel sin reinicio para Debian 13 y mantenía en construcción las versiones para Debian 12 y Oracle Linux UEK, además de las de RHEL 8, 9 y 10, AlmaLinux, Rocky Linux y CloudLinux. Es una solución legítima para bases de datos y appliances, con la salvedad de que solo cubre el kernel y no las bibliotecas de usuario. La cobertura tiene otro límite que conviene decir en voz alta. Un parche en vivo sustituye funciones en memoria y no siempre puede tocar estructuras que ya están en uso. En un fallo de use-after-free como este, la ventana entre la carga del módulo y la estabilidad completa se mide en horas, no en segundos. Quien prefiera el camino lento tiene [la ventana de merge de Linux 7.4](https://observatorioblockchain.com/tecnologia/linux-7-4-merge-window-6753-cambios/) como referencia de cuándo llegan las correcciones a cada rama. Los equipos que optaron por esperar a la versión oficial de su distribución tienen una decisión pendiente. En Ubuntu, los kernels 5.15.0-203.213 para 22.04, 6.8.0-149.149 para 24.04, 7.0.0-43.43 para 26.04 y 7.3.0-10.10 para 26.10 estaban en preparación al cierre de esta semana, sin fecha de publicación. Ubuntu 20.04 y anteriores siguen vulnerables y ya no reciben kernels nuevos por la vía normal.