CVE-2026-98432: Ubuntu y RHEL siguen sin parche, y un modelo Claude ya escribió el exploit

Los dos datos sobre CVE-2026-98432 no encajan bien entre sí. Se trata de un use-after-free en el handshake TCP de IPv4 del kernel de Linux, alcanzable a través de la red sin inicio de sesión y sin interacción, y el equipo de CVEs del kernel le otorgó una puntuación de 9,8. A 30 de octubre de 2026, Ubuntu no tiene ninguna corrección publicada para 22.04, 24.04, 26.04 ni 26.10, y Red Hat incluye RHEL 8, 9 y 10 como afectados, sin corrección y sin mitigación avalada. El segundo dato es que el 27 de octubre, Anthropic publicó una investigación según la cual un modelo Claude aún no publicado produjo una prueba de concepto funcional para obtener root remoto sin autenticación contra un servidor con un listener MPTCP: unos 48 minutos para filtrar una dirección del kernel y cinco más para lograr la ejecución de comandos.

Una vulnerabilidad que los dos mayores proveedores empresariales de Linux aún no pueden parchear, con un exploit funcional escrito en parte por una máquina, no es un Martes de parches rutinario. Es el caso que decide si tu proceso de actualización del kernel y tu política de acceso de agentes tienen algo que ver entre sí.

El bug, en un solo párrafo

Cuando se está estableciendo una conexión TCP, las opciones IP adjuntas al paquete entrante se entregan al nuevo socket en lugar de copiarse. Si el handshake se retransmite, el paquete puede procesarse en una CPU distinta de la que posee el búfer de opciones, y esa segunda CPU puede leer memoria que la primera ya ha liberado. Existe una carrera similar en la ruta de migración de solicitudes. El rango afectado comienza en el kernel 4.4, es decir, la mayoría de las máquinas que aún ejecutan un kernel mantenido. La corrección upstream, commit code>e3f33b0a1d89/code>, retrasa la liberación de los búferes de opciones hasta que ningún otro núcleo pueda seguir manteniendo una referencia.

La explotabilidad se deriva de la mecánica: sin autenticación, sin interacción del usuario, una ruta accesible desde la red y una condición de carrera que se puede reintentar. El propio resumen de Anthropic sobre por qué el PoC es práctico se basa exactamente en esa propiedad: perder una carrera hace fallar un handshake en lugar de tumbar la máquina, así que el atacante lo intenta de nuevo.

Tres proveedores, tres números de gravedad

El desglose de la puntuación es la parte que vale la pena interiorizar, porque decide si tu escáner abre un ticket esta semana.

• Equipo de CVE del kernel — 9.8, crítica. Alcanzable por red, no requiere privilegios, sin interacción.

• Red Hat — 8.1, Importante. La posición de la empresa es que la carrera es difícil de ganar en la práctica.

• Ubuntu — Prioridad alta, sin puntuación numérica publicada en las páginas comprobadas.

La diferencia entre 9,8 y 8,1 no es una discrepancia sobre el bug; es una discrepancia sobre la probabilidad de ganar una carrera. Ambas son defendibles, y la diferencia importa a nivel operativo: un 9,8 con un PoC público es una emergencia; un 8,1 con una carrera difícil es una corrección programada. Hasta que alguien publique cifras de reproducción sobre hardware real, la lectura honesta es que la carrera es ganable, dado que, según se informa, un modelo de frontera la ganó.

¿Quién tiene una solución y quién no?

A fecha de 29–30 de octubre, el panorama es desigual de tal manera que pilla a quienes asumen que un kernel estable implica uno parcheado.

• Debian 12 bookworm — corregido en 6.1.190-1 mediante DLA-4841-1.

• Debian 13 trixie — corregido en 6.12.113-1 mediante DSA-6568-1.

• Ubuntu 22.04, 24.04, 26.04, 26.10 — sin corrección publicada; trabajo en curso.

• Ubuntu 16.04, 18.04, 20.04 — vulnerable, sin corrección publicada.

• RHEL 8, 9, 10 y OpenShift 4 — afectado, sin corrección y sin mitigación avalada por Red Hat.

• RHEL 6 y 7 — no afectados.

• Amazon Linux 2023 — kernel 6.18 reportado como corregido; Oracle Linux UEK reportado como corregido; SUSE informa que algunas versiones están corregidas y otras siguen en pruebas, sin especificar cuáles.

Las versiones estables upstream que incluyen la corrección 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 — que es la lista con la que contrastar tu propia compilación si compilas tu kernel en lugar de usar un paquete de distribución.

Por qué MPTCP sigue surgiendo

El error no es específico de MPTCP, y ahí es donde muchos de los análisis se equivocan. Red Hat considera que cualquier servicio TCP accesible puede ser un posible desencadenante. Lo que MPTCP aporta es una ruta demostrada, y lo que aporta el tráfico es Go: la versión 1.24 y posteriores habilitan multipath TCP por defecto para los sockets de escucha de Linux cuando el kernel tiene MPTCP activado. El equipo de seguridad de Go advirtió sobre esta combinación el 29 de octubre.

Así que «deshabilitar MPTCP» elimina la ruta que Anthropic demostró, no la vulnerabilidad. Es una medida provisional defendible con una salvedad concreta: vale la pena hacerlo en servicios Go hoy, y no sustituye un kernel parcheado.

Las comprobaciones son breves:

• code>ss -Mltnp/code> — enumera los sockets que usan MPTCP actualmente.

• code>net.mptcp.enabled/code> — si la función del kernel está activada en absoluto.

• code>net.ipv4.tcp_migrate_req/code> — desactivado de forma predeterminada; si lo activó, vuelva a desactivarlo.

En concreto, para Go, code>GODEBUG=multipathtcp=0/code> en tiempo de ejecución, o una línea code>godebug/code> en code>go.mod/code>, excluye el binario.

Ninguna de estas cuenta con el respaldo del proveedor. Red Hat declara sin rodeos que no tiene ninguna mitigación que cumpla su propio estándar, lo que es una frase más útil que una lista de soluciones alternativas cargadas de esperanza.

Lo que Anthropic publicó realmente

La investigación es limitada y específica. Un modelo Claude no publicado, al que se le proporcionaron el CVE y un objetivo con un listener MPTCP, produjo una cadena que filtró una dirección del kernel en unos 48 minutos y alcanzó la ejecución de comandos aproximadamente cinco minutos después. Anthropic no ha publicado el exploit y, a fecha del 29 de octubre, ni los proveedores ni el registro del CVE habían reportado ataques en la naturaleza; la vulnerabilidad no está en el catálogo KEV de CISA. El 30 de octubre, un repositorio de GitHub de terceros publicó herramientas de laboratorio para desencadenar condiciones de carrera y filtrar memoria — un arnés de reproducción que no llega a la ejecución completa de código.

Esa combinación es la parte interesante. La capacidad se demuestra, el arma se retiene, y el detalle clave —la propiedad de reintento que convierte una condición de carrera frágil en una fiable— se explica públicamente en prosa. Cualquiera que pueda reproducir la condición de carrera ahora sabe por qué vale la pena insistir en ella.

Qué hacer esta semana

• Aplique los parches y reinicie cuando exista una solución. Una corrección del kernel que está instalada pero no se ha reiniciado no es una solución; verifíquelo con code>uname -r/code>.

• Donde tu distribución no tiene parche — Ubuntu 22.04 a 26.10, RHEL 8 a 10 — decide ahora si tomarás un parche en vivo del proveedor, pasarás a una versión que esté corregida o aceptarás la exposición con MPTCP desactivado en servicios Go.

• Inventaría la exposición de MPTCP en lugar de asumir que está desactivado. El valor predeterminado cambió en Go, no en tu configuración, y un cambio en un valor predeterminado es invisible en un diff de configuración.

• Ensaye el reinicio. Este tipo de corrección requiere un reinicio completo, y las organizaciones que más tiempo perderán son aquellas que descubren su plan de conmutación por error durante la ventana de mantenimiento.

Las dos preguntas que este CVE realmente plantea

El primero trata de la generación de exploits, y no es filosófico. Un modelo encontró una secuencia que muchísimos investigadores humanos no habían encontrado, en un objetivo con una configuración habilitante específica, en menos de una hora. Se publique o no el exploit, la línea de tiempo ha cambiado: la ventana entre un aviso público y un exploit funcional ahora se mide frente a modelos que leen el aviso.

El segundo trata de qué significa aplicar parches cuando los proveedores no pueden hacerlo. La distribución que te entrega un kernel y el kernel que tiene la corrección no son el mismo objeto, y la brecha entre ambos es exactamente donde vive esta vulnerabilidad para la mayoría de los lectores de esta publicación. El OrcaRouter AI Incident Archive indexa incidentes como este junto con sus fuentes primarias, gravedad y confianza, que es la versión de esta historia que vale la pena conservar una vez que el ciclo de noticias avance.

Lo que no hay que hacer es archivar esto bajo «esperar al proveedor». La propia página del proveedor dice que todavía no hay nada que esperar.

Nota sobre las fuentes: el mecanismo, el rango afectado desde el kernel 4.4 y el commit upstream code>e3f33b0a1d89/code>, la lista de versiones estables y la guía de mitigación proceden del registro de CVE y de los avisos de distribución leídos el 30 de octubre de 2026. Las calificaciones 9.8, 8.1 y Alta de Ubuntu son del equipo de CVE del kernel, de Red Hat y de Canonical, respectivamente. El estado de los parches por distribución procede de DLA-4841-1 y DSA-6568-1 de Debian, de las páginas de CVE de Red Hat y Ubuntu, y de declaraciones de proveedores en la misma fecha. La cronología de la prueba de concepto, las cifras de 48 minutos y cinco minutos, y la propiedad de reintento son de la investigación de Anthropic del 27 de octubre, que no divulgó el exploit. El repositorio de laboratorio del 30 de octubre se describe como de terceros y no es nuestro.