- La vulnerabilidad CVE-2026-98432 afecta al código TCP IPv4 y permite, en ciertas condiciones, ejecutar comandos como root.
- El fallo está presente desde Linux 4.4; IPv6 no se ve afectado por esta condición concreta.
- Debian, Oracle Linux, SUSE y Amazon Linux han publicado parches, mientras Ubuntu y Red Hat mantienen actualizaciones pendientes en varias ramas.
- La recomendación principal es instalar el kernel corregido, reiniciar y verificar que el sistema ha arrancado con la versión nueva.
La actualidad del kernel de Linux vuelve a girar en torno a la seguridad. El CVE-2026-98432 ha pasado de ser una ficha técnica a una alerta con consecuencias muy concretas: afecta al código de red IPv4 presente en innumerables sistemas y obliga a revisar la hoja de ruta de actualización de servidores, equipos industriales y servicios en la nube. La combinación de un fallo de memoria, una demostración de exploit y parches que no llegan al mismo ritmo en todas las distribuciones ha encendido las alarmas.
El problema no se limita a un aviso teórico. La vulnerabilidad permite, bajo determinadas condiciones, que un atacante remoto no autenticado llegue a ejecutar comandos con privilegios de root o, como mínimo, provoque corrupción de memoria y caídas del sistema. En España y Europa, donde hay muchas infraestructuras empresariales apoyadas en Ubuntu, Red Hat, Debian o SUSE, la pregunta ya no es si conviene actualizar, sino cuánto se puede esperar sin asumir un riesgo innecesario.
Un fallo de memoria en TCP IPv4 con alcance industrial
La raíz técnica está en una condición de carrera durante el establecimiento de conexiones TCP IPv4. El kernel puede liberar una zona de memoria mientras otra CPU sigue utilizando datos vinculados a esa conexión, lo que desemboca en un use-after-free. Esa situación abre la puerta a comportamientos impredecibles, corrupción de memoria y, en el peor escenario, ejecución de código. El parche corrige el problema haciendo que el sistema espere a que otras CPU terminen de leer antes de liberar la memoria asociada.
El alcance es amplio porque el fallo acompaña al kernel desde la versión 4.4. Eso incluye servidores, routers domésticos, equipos industriales, dispositivos conectados y muchas imágenes de contenedor. IPv6 queda fuera de esta condición concreta por diferencias internas en la gestión de opciones de conexión. La corrección se aplicó en el árbol principal el 5 de octubre, pero la exposición no desaparece hasta que cada distribución empaqueta el kernel corregido y cada administrador lo instala.
Qué distribuciones han movido ficha y cuáles siguen esperando
El panorama de parches es desigual. Debian, Oracle Linux, SUSE y Amazon Linux ya han publicado kernels corregidos al menos para algunas de sus ramas soportadas. En el caso de Debian, la actualización alcanza a versiones afectadas de sus repositorios estables; Oracle, SUSE y Amazon han movido ficha en sus ramas de soporte. Para quien compila su propio kernel, las versiones corregidas incluyen las ramas 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 y 7.3, además de la candidata 7.3-rc7.
La parte incómoda está en Ubuntu y Red Hat Enterprise Linux. Ubuntu mantiene el trabajo en preparación para ramas actuales como 22.04, 24.04, 26.04 y 26.10, mientras Red Hat no garantiza una fecha concreta para varias versiones de RHEL 8, 9 y 10, ni para OpenShift 4. En entornos de producción eso deja a los equipos ante una decisión delicada: esperar el paquete oficial, aplicar mitigaciones temporales o adelantar una ventana de mantenimiento con más riesgo del habitual.
No conviene confundir una mitigación con una solución definitiva. Desactivar MPTCP puede reducir la superficie de ataque en algunos servicios, pero el fallo de fondo no depende solo de esa característica. El equipo de seguridad de Go avisó de que desde Go 1.24 algunos programas pueden activar MPTCP por defecto en sockets de escucha, así que revisar configuraciones y servicios expuestos es sensato, aunque el paso realmente fiable sigue siendo instalar un kernel parcheado.
La severidad no es la misma para todos
La discrepancia de puntuaciones explica parte del ruido. El equipo de CVE del kernel calificó el fallo con 9,8 sobre 10, asumiendo baja complejidad de ataque y un escenario grave de ejecución remota. Esa nota convierte la vulnerabilidad en una prioridad alta para cualquier comité de riesgos. Sin embargo, no todos los proveedores comparten el mismo criterio sobre lo fácil que resulta ganar la condición de carrera.
Red Hat, Oracle, SUSE y Amazon han situado sus valoraciones en horquillas que van aproximadamente entre 5,9 y 8,1, con Amazon en torno a 7,0. Red Hat llegó a calificarla como moderada en una de sus fichas, aunque su aviso legible por máquina elevó el impacto a importante con 8,1. La diferencia no es un simple error de cálculo: refleja supuestos distintos sobre la complejidad del ataque, las condiciones de red necesarias y el impacto real en confidencialidad, integridad y disponibilidad.
Para un administrador, esa brecha se traduce en una pregunta muy práctica. Si el proveedor de su distribución puntúa el fallo por debajo de 9, quizá lo incluya en el ciclo mensual; si mira la ficha del kernel, verá una emergencia. Mientras ambas cifras convivan, la priorización dependerá de qué documento se lea primero. La recomendación técnica, en cambio, es bastante clara: actualizar en cuanto haya kernel disponible y no esperar a que todas las fichas se pongan de acuerdo.
La IA acorta el tiempo entre el aviso y el exploit
El elemento que ha cambiado la percepción del riesgo es la demostración de exploit. Un modelo de investigación de Anthropic generó un exploit funcional para este fallo, capaz de dar shell de root a un atacante remoto no autenticado en determinadas configuraciones. La compañía no publicó el código completo ni todos los detalles de la configuración utilizada, pero sí confirmó que el modelo había identificado el objetivo y construido una cadena de ataque viable.
El tiempo que se ha manejado en la demostración es llamativo: alrededor de 48 minutos para obtener información útil del kernel y unos cinco minutos más para alcanzar la ejecución de comandos. Es decir, menos de una hora de trabajo efectivo para pasar de una ficha técnica a una prueba de concepto con privilegios elevados. Esa velocidad comprime la ventana tradicional entre la publicación de una vulnerabilidad y su explotación, que durante años se medía en semanas.
También hay una cara menos negativa. La misma tecnología que acorta el margen de reacción sirve para auditar código antiguo a una escala difícil de igualar con revisión humana. El hallazgo salió de una búsqueda sistemática asistida por IA y acabó destapando un error que había pasado inadvertido durante años. La IA encuentra y acelera, pero también obliga a revisar; el problema es que las distribuciones y los equipos de sistemas no siempre avanzan a la misma velocidad que un modelo capaz de escribir un exploit en una tarde.
Medidas razonables mientras llega la actualización
La primera medida sigue siendo la de siempre: instalar el kernel corregido y reiniciar. No basta con aplicar el paquete si el sistema continúa ejecutando el kernel anterior. En flotas grandes conviene comprobar que el reinicio se ha completado, que la máquina ha arrancado con la versión nueva y que ningún despliegue automático ha devuelto el servidor al estado previo. Para servicios que no pueden reiniciarse de inmediato, toca revisar qué puertos exponen IPv4 a redes no confiables y reducir la superficie todo lo posible.
El vector demostrado pasa por servicios con un listener de MPTCP, pero el error subyacente no es exclusivo de esa función. Por eso, desactivar MPTCP solo como medida temporal puede ayudar a ganar tiempo, no a cerrar el agujero. Si hay servicios escritos en Go, conviene revisar si están activando esa característica por defecto; si se usan contenedores, imágenes base antiguas o equipos industriales, es probable que la actualización dependa de un proveedor externo y no de una simple orden en el terminal.
La exposición tampoco se limita a servidores grandes. Routers, cámaras, dispositivos conectados y equipos industriales comparten en muchos casos el mismo código de red. Algunos no volverán a recibir actualizaciones en su vida útil, lo que convierte este tipo de fallos en un problema de inventario y no solo de parcheo. Saber qué kernel corre en cada máquina es casi tan importante como saber que existe una actualización; sin ese dato, cualquier plan de respuesta se queda a medias.
De momento no hay constancia pública de ataques masivos asociados a este CVE, y las plataformas de cómputo que ya se han pronunciado aseguran no haber detectado explotación en sus entornos. Esa tranquilidad relativa no debería convertirse en excusa. El exploit existe, el fallo es público y los parches no llegan igual a todas partes; en cuanto haya una versión corregida para la distribución que corresponda, lo razonable es aplicarla y dejar de depender de mitigaciones parciales.
La prioridad práctica es sencilla de enunciar y difícil de ejecutar en una infraestructura grande: inventario actualizado, ventanas de mantenimiento claras y verificación después del reinicio. Ubuntu y Red Hat siguen siendo los nombres que más preocupan por sus plazos pendientes, mientras Debian, Oracle, SUSE y Amazon ya han dado pasos para parte de sus ramas. Quien tenga servicios expuestos a Internet y no pueda actualizar de inmediato debería reducir la superficie, revisar MPTCP y preparar el cambio de kernel cuanto antes; quien ya tenga el parche, debe confirmar que el sistema está realmente ejecutándolo.