CVE-2026-98432: el kernel Linux permite root remoto bajo ciertas condiciones MPTCP
Un fallo de TCP IPv4 afecta a kernels Linux desde 4.4. Un exploit de laboratorio alcanzó root en un listener MPTCP, pero Red Hat valora el caso como una carrera compleja cuyo impacto práctico conocido es denegación de servicio.
CVE-2026-98432 afecta al código de red IPv4 del kernel Linux y abre una carrera de memoria en el manejo de solicitudes TCP. Investigadores de Anthropic demostraron en laboratorio que un exploit podía ejecutar comandos como root contra un servidor con un listener de Multipath TCP (MPTCP). La demostración vuelve urgente revisar el inventario, aunque no significa que cualquier servidor Linux expuesto a Internet sea explotable de la misma manera.
El fallo es un use-after-free: una ruta del kernel transfiere opciones de una solicitud de conexión a un socket hijo mientras otro procesador todavía puede leerlas. Si la carrera coincide con la liberación de esa memoria, el kernel trabaja con una referencia caducada. El aviso de Red Hat describe el resultado práctico como una posible caída del sistema y denegación de servicio; el equipo CNA del kernel asignó una puntuación de 9,8, y el exploit de laboratorio de Anthropic elevó el interés por un escenario de ejecución remota más grave.
-InfraCrew dice: una puntuación alta sirve para ordenar el triage; no convierte por arte de magia cada condición de carrera en una intrusión confirmada.-
El alcance depende de la ruta de red
MPTCP permite que una conexión TCP use varias rutas de red dentro de una misma sesión. La demostración de ejecución remota necesitó un listener MPTCP y tardó alrededor de 53 minutos en alcanzar root, según el reporte recogido por BleepingComputer. Eso es evidencia de capacidad en un laboratorio, no de ataques observados contra servidores en producción: al 30 de octubre no se habían confirmado explotaciones en el entorno real.
El matiz importa porque el defecto está en TCP IPv4, no únicamente en la implementación de MPTCP. La cobertura técnica indica que las conexiones TCP ordinarias también pueden activar el fallo, aunque no se había demostrado ejecución remota fuera del escenario MPTCP; Red Hat, por su parte, destaca la complejidad de ganar la carrera y no acredita impacto sobre confidencialidad o integridad. Desactivar MPTCP, por tanto, no debe tratarse como una mitigación completa.
-InfraCrew dice: si el parche temporal consiste en “apaguemos MPTCP y ya”, conviene releer el alcance antes de convertir una hipótesis en cambio de producción.-
Qué revisar en distribuciones distintas
El defecto se remonta a Linux 4.4, pero la versión upstream no basta para decidir si una máquina está corregida: las distribuciones mantienen ramas y aplican backports propios. BleepingComputer informa de correcciones publicadas para Debian 12 y 13, mientras que Canonical y Red Hat todavía tenían trabajo pendiente el 30 de octubre. Red Hat marca como afectados RHEL 8, 9 y 10; RHEL 7 no contiene el código vulnerable y queda fuera de este caso.
El primer paso útil es cruzar distribución, kernel instalado y advisory del proveedor, incluyendo appliances y nodos de plataforma que no siempre aparecen en el inventario de servidores generalistas. En una flota heterogénea no existe un único número de versión que cierre el asunto. También conviene identificar servicios con listeners MPTCP y sockets TCP accesibles desde redes menos confiables, sin asumir que la ausencia de una aplicación MPTCP visible elimina el riesgo de denegación de servicio.
Parche primero; mitigación con límites claros
La corrección upstream ya existe, pero su llegada a las ramas empresariales depende del ciclo de cada proveedor. Instala el paquete corregido cuando esté publicado para la distribución concreta y verifica el kernel efectivo después de la actualización o del reinicio que exija esa plataforma. Si el proveedor aún no publica un paquete, su advisory debe guiar cualquier medida temporal: Red Hat no considera que haya una mitigación general que cumpla sus criterios de facilidad, cobertura y estabilidad.
La evidencia disponible justifica priorizar exposición y seguimiento, pero no afirmar que haya una campaña activa ni que todos los kernels afectados permitan root remoto con la misma facilidad. Comprueba las notas del proveedor antes de tocar parámetros de red; el caso muestra que una opción de protocolo puede ser relevante para la explotación demostrada sin ser la única ruta que dispara el defecto.
-InfraCrew dice: cerrar el ticket al ver “kernel actualizado” sin comprobar el build instalado es una forma eficiente de conservar el riesgo en el inventario.-
Diccionario de la Crew
MPTCP — Extensión de TCP que permite transportar una conexión lógica por varias rutas de red.
Use-after-free — Error de memoria que aparece cuando un componente vuelve a usar una zona que ya fue liberada.
Backport — Adaptación de una corrección nueva a una rama de software anterior que sigue recibiendo soporte.
CNA — Autoridad autorizada para asignar y mantener registros de vulnerabilidades CVE.
