Linux 核心修補 CVE-2026-98432 TCP UAF 漏洞，Ubuntu 和 RHEL 仍受影響

Un atacante remoto, sin usuario ni contraseña, puede leer memoria del kernel, corromperla o tumbar el servidor con solo mandarle paquetes de conexión TCP: así describe la autoridad de numeración del propio kernel de Linux la CVE-2026-98432, la falla crítica de Linux que corrigió este mes con un parche de cuatro líneas.

El bug vive desde la versión 4.4, lanzada en 2016, en el código que procesa el saludo TCP sobre IPv4. Red Hat subió su calificación a Critical el 30 de octubre, Ubuntu sigue marcando sus kernels como vulnerables, y Anthropic dice que su modelo Claude escribió un exploit que da acceso root remoto sin necesitar ninguna credencial.

TL;DR

• CVE-2026-98432: use-after-free crítico (CVSS 9.8) en TCP de Linux, explotable sin credenciales.- Anthropic reportó el bug y dice que Claude escribió un exploit root funcional para servidores con multipath TCP.- Red Hat subió la calificación a Critical el 30 de octubre y lista RHEL 8, 9 y 10 sin parche aún.- Ubuntu marca la falla como vulnerable en todas sus versiones al 31 de octubre de 2026, sin parche publicado.- El equipo de seguridad de Go advierte que sus programas abren listeners multipath TCP por defecto, ampliando el riesgo.

Qué es la falla crítica de Linux

CVE-2026-98432 es la falla crítica de Linux que corrige un use-after-free en el código IPv4 que procesa el saludo TCP. El kernel libera la memoria que guarda las opciones IP de una solicitud de conexión y, por una condición de carrera, otra ruta del código todavía puede leerla o escribirla después de liberada.
El parche definitivo cambia solo cuatro líneas en el subsistema de red del kernel.

Qué pasó

El kernel estable de Linux publicó el parche el 11 y el 15 de octubre de 2026. Las versiones corregidas son 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 y 7.3. El registro se publicó en cve.org el 15 de octubre, y la autoridad de numeración del kernel le puso 9.8 sobre 10 en CVSS 3.1: la nota máxima para un fallo que no necesita usuario ni interacción.

El 30 de octubre, Red Hat subió su propia calificación de Important (8.1) a Critical (9.8) y publicó un boletín con una mitigación temporal. Al día siguiente, a las 5:15 PM CDT del 31 de octubre, el rastreador de Ubuntu todavía marcaba el paquete linux como "Vulnerable" en cada versión soportada, sin ningún aviso de seguridad publicado. Red Hat Enterprise Linux 8, 9 y 10, junto con OpenShift Container Platform, aparecen en la misma situación: afectados, sin parche disponible.

No todas las distribuciones van atrasadas. AlmaLinux tiene kernels corregidos para sus versiones 8, 9 y 10 en su repositorio de pruebas desde el 30 de octubre, un día antes que Red Hat, de quien deriva su base. Amazon Linux ya corrigió todos sus kernels. Debian, SUSE Enterprise y Oracle UEK también cuentan con versiones parchadas desde antes de que Red Hat subiera la calificación.
DistribuciónEstado al 31 de octubre de 2026Versión corregidaUbuntuVulnerable en todas las versiones soportadasSin kernel corregido todavíaRed Hat Enterprise Linux (8, 9, 10)Afectado, calificación subida a Critical el 30 de octubreSin kernel corregido todavíaAlmaLinux (8, 9, 10)Kernel corregido en repositorio de pruebas desde el 30 de octubrekernel-4.18.0-553.180.2.el8_10 y equivalentesAmazon LinuxTodos los kernels ya corregidosDisponibleDebian / SUSE Enterprise / Oracle UEKKernels ya corregidosDisponible

Contexto e historia

La vulnerabilidad del kernel de Linux la reportó Xinyang Ge, investigador de Anthropic. El commit que la corrige, titulado "ipv4: free inet_opt and ireq_opt after an RCU grace period", lo firma Eric Dumazet y lo revisó Kuniyuki Iwashima, dos de los mantenedores habituales del subsistema de red del kernel.

El fallo de seguridad en el kernel arrastra siete años de historial: la primera versión afectada es la 4.4, y solo queda fuera de alcance la rama de 4.4 a 5.4 porque ya llegó a su fin de vida upstream y no recibirá parche oficial del proyecto Linux; las distribuciones que aún la mantienen deben portar el fix por su cuenta. El cambio real en el código fuente, según detalla Atlas, ocupa apenas cuatro líneas: mover la liberación de la memoria a después del período de gracia de RCU, el mecanismo que usa el kernel para saber cuándo ya nadie más está leyendo una estructura antes de borrarla.

Detalles técnicos: por qué funciona el exploit

Cuando llega un paquete SYN con opciones IPv4 (por ejemplo, un registro de ruta), el kernel crea un "request socket" temporal y guarda esas opciones en dos punteros, inet_opt e ireq_opt. Si la solicitud expira o se procesa fuera de orden, una ruta del código libera esa memoria; si, casi al mismo tiempo, otra ruta sigue completando el saludo TCP con el ACK final, intenta leer la memoria que la primera ruta ya liberó.

sequenceDiagram
participant C as Atacante remoto
participant K as Kernel de Linux
participant M as Opciones IPv4 en memoria
C->>K: envía SYN con opciones IPv4
K->>M: asigna ireq_opt para la solicitud
Note over K,M: el temporizador de la solicitud vence
K->>M: libera ireq_opt tras el período de gracia RCU
C->>K: envía el ACK final del saludo
K->>M: intenta leer ireq_opt ya liberado
Note over C,M: use after free, fuga o corrupción de memoria del kernel

Ese es el patrón clásico de un use-after-free: dos caminos de ejecución que no se coordinan sobre quién es dueño de un bloque de memoria. Según la puntuación de la propia CNA del kernel, las consecuencias van desde exponer contenido del heap del kernel al peer remoto, hasta corromper memoria o colgar la máquina.

IPv6 no está afectado por este problema en particular: el propio mensaje del commit lo aclara, porque esa pila de red no comparte el mismo camino de opciones IP. La ventana de ataque tampoco depende de ninguna aplicación en particular, porque el saludo TCP se procesa dentro del kernel antes de que la conexión llegue a cualquier programa de espacio de usuario.
Multipath TCP combina varias rutas de red en una sola conexión, y los programas en Go lo activan por defecto.

Impacto y análisis

La vulnerabilidad del kernel de Linux alcanza a cualquier servidor, físico o virtual, que use un kernel 4.4 o posterior sin el parche, y eso incluye a los contenedores: un contenedor comparte el kernel del host, así que una imagen nueva no cambia nada si la máquina que la ejecuta sigue vulnerable.

Lo que amplía el riesgo real es Multipath TCP (MPTCP), la extensión que permite combinar varias rutas de red en una sola conexión. El exploit que construyó Claude necesita, según Anthropic, "servidores Linux con un listener multipath TCP" y ninguna credencial. El equipo de seguridad de Go advierte que los programas escritos en ese lenguaje abren ese tipo de listener por defecto, así que la configuración que requiere el ataque es más común de lo que parecía al principio: no depende de que un administrador la haya activado a propósito.

⚠️ Ojo: si tu servidor corre un binario de Go con un listener TCP, probablemente tenga multipath TCP activado sin que lo hayas pedido. Revisalo antes de asumir que el ataque no te toca.

El episodio también deja un dato incómodo sobre el estado de la inteligencia artificial en seguridad: la misma falla crítica de Linux que un investigador humano reportó terminó con una prueba de concepto escrita por un modelo, capaz de convertir un bug remoto en acceso root sin usuario ni contraseña. Anthropic no publicó el exploit, pero que un modelo pueda llegar a ese resultado cambia el cálculo de cuánto tiempo pasa entre que se conoce un bug y que alguien lo convierte en un arma.

Qué sigue

Lo primero es revisar el rastreador de tu propia distribución, porque los números de versión no coinciden entre el kernel upstream y el que empaqueta cada distribución. Para confirmar si tu kernel ya tiene el parche, corré uname -r y comparalo contra la tabla de versiones corregidas: un resultado como 6.12.113-generic ya incluye el fix si el número coincide o es posterior al listado arriba. En Ubuntu Pro, el comando pro fix CVE-2026-98432 --dry-run indica directamente si el paquete instalado sigue expuesto.

Mientras llega el parche, Red Hat propone una mitigación con nftables en su boletín RHSB-2026-016, y Atlas sugiere una regla provisional: descartar los paquetes TCP que llevan opciones IPv4. Ambas opciones cortan también tráfico legítimo que use esas opciones, así que conviene aplicarlas solo mientras llega el kernel definitivo. Si no usás multipath TCP, desactivarlo reduce la superficie de ataque sin tocar el resto del tráfico; si lo usás, priorizá parchear esos hosts primero.

📖 Resumen en Telegram: Ver resumen

Probalo vos: revisá el estado de tu kernel contra el rastreador de tu distribución y, si corrés Ubuntu o RHEL, aplicá ya la regla de nftables del boletín de Red Hat mientras llega el parche definitivo.

Preguntas frecuentes

¿Qué es CVE-2026-98432?

Es el identificador del bug CVE-2026-98432, un use-after-free en el código IPv4 del kernel de Linux que un atacante remoto y sin autenticar puede explotar durante el saludo TCP.

¿Qué versiones de Linux corrigen el fallo de seguridad en el kernel?

Las ramas estables corregidas son 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 y 7.3. Las versiones entre 4.4 y 5.4 llegaron a su fin de vida upstream y no reciben parche oficial del proyecto Linux.

¿La vulnerabilidad del kernel de Linux afecta a contenedores?

Sí, porque un contenedor usa el kernel del host. Si ese kernel no tiene el parche, ningún cambio dentro de la imagen del contenedor evita el problema.

¿Qué es Multipath TCP y por qué amplía el riesgo?

Multipath TCP (MPTCP) es una extensión de TCP que combina varias rutas de red en una sola conexión. El exploit que construyó Claude necesita un servidor con un listener multipath TCP activo, y los programas en Go abren ese tipo de listener por defecto.

¿Cómo mitigar el use-after-free en TCP si todavía no hay kernel corregido?

Red Hat recomienda una regla de nftables en su boletín RHSB-2026-016, y Atlas propone descartar paquetes TCP con opciones IPv4 mientras tanto. Desactivar multipath TCP, si no lo usás, también reduce la exposición.

¿Escribió Claude un exploit funcional para esta falla crítica de Linux?

Según Anthropic, sí: su modelo construyó una prueba de concepto que ejecuta comandos como root en servidores con un listener multipath TCP, sin necesitar ninguna credencial. La compañía no publicó el código del exploit.

Referencias

• Atlas: cobertura y seguimiento en vivo del estado de parches por distribución para CVE-2026-98432.- National Vulnerability Database: registro oficial de la vulnerabilidad con su puntuación CVSS.- CVE.org: ficha pública del identificador CVE-2026-98432 asignado por la CNA del kernel de Linux.- Red Hat: página de seguimiento de la CVE con la calificación Critical y el boletín de mitigación RHSB-2026-016.- Ubuntu Security: rastreador de estado del paquete linux por versión soportada.

📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.