Un fallo TCP del kernel Linux da root remoto y Ubuntu sigue sin parche

Durante 48 minutos, un exploit escrito por un modelo interno de Anthropic bombardeó con paquetes SYN un servidor Linux hasta filtrar un puntero del kernel, y cinco minutos después ejecutaba comandos como root sin credenciales ni intervención de nadie. El fallo, CVE-2026-98432, es un use-after-free en el handshake TCP de IPv4 que lleva en el kernel desde Linux 4.4, se corrigió upstream el 5 de octubre de 2026 y, a las 18:00 UTC del 30 de octubre, Ubuntu y Red Hat Enterprise Linux siguen sin paquete parcheado.

• El fallo: use-after-free en las opciones IP de una conexión TCP IPv4, presente desde Linux 4.4, con 9,8 para el CNA del kernel y 8,1 para SUSE, Oracle y Amazon.
• El exploit: un modelo de investigación de Anthropic obtuvo root remoto en un servidor con listener MPTCP en 53 minutos, sin código publicado ni explotación conocida fuera del laboratorio.
• Los parches: Debian, Oracle, SUSE y Amazon Linux 2023 tienen kernels corregidos. Ubuntu y RHEL, no.
• La acción urgente: comprueba si tienes listeners MPTCP (los programas Go los abren por defecto desde Go 1.24), desactívalos si puedes y actualiza el kernel en cuanto haya paquete.

Una SYN con opciones IPv4 y una carrera que el atacante puede repetir

El fallo vive en la forma en que el kernel guarda las opciones IP de una conexión entrante. Cuando llega una SYN con la opción Record Route o Timestamp, el kernel almacena esas opciones en el request socket, y al completar el handshake se las cede al socket hijo sin copiarlas. Si entre tanto llega una retransmisión de la misma SYN, otra CPU puede estar construyendo la SYNACK y leyendo esas opciones justo cuando el socket hijo se destruye y las libera con un kfree() normal. El resultado es una lectura de memoria liberada en ip_options_build(). La ficha del equipo CVE del kernel lo explica así y añade una segunda vía, la migración de request sockets, que solo entra en juego con net.ipv4.tcp_migrate_req=1 o con un programa BPF de tipo SK_REUSEPORT_SELECT_OR_MIGRATE.

La corrección es pequeña. El commit e3f33b0a1d89, que entró en la rama principal el 5 de octubre, sustituye kfree() por kfree_rcu() en inet_sock_destruct() y en tcp_v4_reqsk_destructor(), de modo que la memoria no se libera hasta que ningún lector RCU la use. Toca dos ficheros, net/ipv4/af_inet.c y net/ipv4/tcp_ipv4.c. IPv6 no sufre la primera vía porque tcp_v6_syn_recv_sock() duplica las opciones en lugar de cederlas, aunque el equipo del kernel reconoce que la variante de migración existe también en IPv6 a través de CALIPSO y queda para otro parche.

El equipo CVE del kernel publicó el identificador el 15 de octubre y añadió la puntuación el 24, con el vector que corresponde a un ataque de red, sin autenticación y de complejidad baja. Esa última letra es la que discuten las distribuciones, y a ella volveremos. NVD muestra la puntuación del CNA y, a 30 de octubre, no ha añadido análisis propio. Las versiones que cierran el fallo 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. Si tu kernel es anterior a la 4.4, no te afecta, y si pertenece a una rama que ya no recibe mantenimiento, no tendrá versión corregida.

La cadena de dos fases que Anthropic probó contra un listener MPTCP

El 27 de octubre, el Frontier Red Team de Anthropic publicó un informe sobre cinco cadenas de explotación construidas por un modelo de investigación interno que la empresa no ha lanzado. Cuatro afectan a Chrome, Safari, Android y Windows. La quinta es esta: «After initial prompting, Claude wrote an exploit» (tras unas instrucciones iniciales, Claude escribió un exploit) que ejecuta comandos como root en servidores Linux con un listener de Multipath TCP (MPTCP), la extensión que reparte una conexión TCP entre varias rutas.

El exploit tiene dos fases. En la primera aprovecha la carrera para que el kernel lea un campo de longitud controlado por el atacante, copie bytes de más en la SYNACK y se los devuelva. Si alguna de esas lecturas incluye un puntero del kernel, el atacante conoce la disposición de la memoria y KASLR deja de protegerle. En la segunda usa el mismo use-after-free para desbordar un búfer y sobrescribir un puntero de callback con la dirección de un payload que ya había colocado en memoria del kernel mediante una función normal del protocolo. Cuando el kernel invoca el callback, el payload encadena llamadas a funciones existentes y termina lanzando el comando de shell elegido. Anthropic subraya que «a lost race only fails the handshake without crashing the whole system» (una carrera perdida solo hace fallar el handshake sin tumbar el sistema), así que el atacante puede insistir hasta ganar.

Xinyang Ge, uno de los autores del informe, lo resumió en X el 29 de octubre con una recomendación de una línea: «patch it now (or disable mptcp)» (parchea ya, o desactiva MPTCP).

Hay un hueco entre el informe y la ficha del kernel que conviene tener presente. Ni la descripción del CVE ni el commit mencionan MPTCP. Anthropic no ha publicado el código del exploit, la versión del kernel ni la configuración del servidor de pruebas, y tampoco ha dicho si un listener TCP convencional es explotable con la misma cadena. Lo que sí está claro por la descripción del CNA es que la carrera existe en cualquier servicio IPv4 que acepte conexiones, con o sin MPTCP, y que sus efectos van desde la fuga de memoria del kernel en la SYNACK hasta escrituras fuera de límites o un pánico del kernel.

La reacción en la comunidad de seguridad ofensiva llegó el mismo 27 de octubre. El investigador que firma como cts lo resumió en X como «Fully working, end-to-end exploits» (exploits completos y funcionales de principio a fin) y destacó que el modelo recibió instrucciones mínimas.

De 9,8 a 8,1, por qué el mismo fallo lleva tres puntuaciones

La única diferencia entre el 9,8 del equipo del kernel y el 8,1 de SUSE, Oracle, Amazon y la primera versión del archivo CSAF de Red Hat es la complejidad del ataque, Low en un caso y High en el otro. El CNA sostiene que ambos lados de la carrera los provoca el atacante y que la planificación en varios núcleos o el estado del heap no son condiciones fuera de su control. Las distribuciones responden que ganar la carrera cuesta, y que un intento fallido tiene más papeletas de acabar en un cuelgue que en una shell. SUSE lo refleja en sus dos vectores, 8,1 en CVSS 3.1 con AC:H y 9,2 en CVSS 4.0, donde el requisito de ataque pasa a ser una condición de carrera explícita.

Red Hat ha cambiado de opinión en 24 horas. Su archivo CSAF, con fecha de revisión del 30 de octubre y hora 15:03 UTC, marca el fallo como Critical con 9,8 y vector idéntico al del kernel, lista 238 paquetes de RHEL 8, 9 y 10 y de OpenShift 4 como afectados y deja fuera a RHEL 6 y 7. El día anterior ese mismo archivo lo puntuaba en 8,1 como Important, según recogieron The Hacker News y el analista japonés piyolog. En el apartado de mitigaciones, Red Hat escribe que «Mitigation for this issue is either not available» (no hay mitigación disponible para este fallo) o que las existentes no cumplen sus criterios de facilidad de despliegue y estabilidad. Su descripción del impacto sigue hablando de un cuelgue del sistema como resultado principal, con la corrupción de memoria como posibilidad.

En la práctica, la referencia que ordena los parches en muchas empresas españolas es el catálogo KEV de CISA, y CVE-2026-98432 no estaba en él a las 17:02 UTC del 30 de octubre. Ninguna distribución, ni el CNA, ni Anthropic han reportado explotación fuera del laboratorio. Tampoco INCIBE-CERT ni CCN-CERT habían publicado aviso propio al cierre de esta noticia.

Debian, SUSE y Oracle ya tienen kernel y Ubuntu y RHEL siguen en espera

Veinticinco días después del commit upstream, el mapa de parches está partido en dos. El gráfico de Ostorlab lo resume con las fechas de cada hito, desde la autoría del parche el 1 de octubre hasta la situación de Ubuntu y Red Hat el día 30.

Debian fue la primera. Su rastreador de seguridad recoge el DSA-6568-1 del 16 de octubre, que lleva la 6.12.113-1 a trixie, el DLA-4841-1 del 17 de octubre con la 6.1.190-1 para bookworm y el DLA-4850-1 del 22 de octubre con la 6.12.113-1~deb12u1 para el paquete linux-6.12 de bookworm. Las ramas forky y sid tienen 7.2.12-1 y 7.2.13-1. Quien siga en los repositorios normales de bookworm o trixie sin aplicar las actualizaciones de seguridad continúa en 6.1.176-1 o 6.12.107-1, ambas vulnerables.

Oracle publicó el 16 de octubre tres erratas para UEK, ELSA-2026-500397, 500398 y 500399, que cubren Oracle Linux 7, 8, 9 y 10. Amazon Linux 2023 corrigió kernel6.18 el 24 de octubre con ALAS2023-2026-3251 y kernel6.12 el 29 con ALAS2023-2026-3335, que lleva la 6.12.113-138.209, mientras que su kernel por defecto y Amazon Linux 2 siguen pendientes. SUSE emitió nueve avisos el 29 de octubre, con kernel-default 6.12.0-160000.40.1 para SLES 16.0 y paquetes para SUSE Linux Micro 6.2 y las ramas LTSS de SLES 15 SP4, SP5 y SP6, y mantiene SLES 15 SP7 y Micro 6.0 y 6.1 como afectados o en progreso.

Ubuntu asigna prioridad High y, en su actualización de las 22:56 UTC del 29 de octubre, tiene el parche en preparación en las cuatro ramas con soporte: 7.3.0-10.10 para 26.10, 7.0.0-43.43 para 26.04 LTS, 6.8.0-149.149 para 24.04 LTS y 5.15.0-203.213 para 22.04 LTS. Las ramas 20.04, 18.04 y 16.04 figuran como vulnerables sin versión asignada, y 14.04 como no afectada. Es el mismo retraso respecto a Debian que vimos hace cuatro días con el fallo de Brotli en las distribuciones, con la diferencia de que esta vez el aviso del CNA puntúa 9,8 y hay un exploit documentado.

Desactivar MPTCP y filtrar opciones IP mientras llega el kernel de Ubuntu

Lo primero es saber si el servidor tiene listeners MPTCP, porque la única cadena documentada los necesita. Estos tres comandos muestran la versión del kernel, si MPTCP está habilitado y qué sockets MPTCP escuchan:

uname -r
sysctl net.mptcp.enabled
ss -Mltnp

Desde Go 1.24, los programas escritos en Go abren por defecto listeners MPTCP en Linux, así que un servidor que no haya configurado nunca Multipath TCP puede tener varios sin saberlo. El equipo de seguridad de Go lo avisó el 29 de octubre en golang-announce, en un mensaje que Alan Coopersmith reenvió a oss-security: la variable de entorno GODEBUG=multipathtcp=0 lo desactiva en tiempo de ejecución y la línea godebug multipathtcp=0 en el go.mod del módulo principal, en tiempo de compilación. Las llamadas a SetMultipathTCP en el código prevalecen sobre ambas. El propio equipo lo califica de «fragile mitigation» (mitigación frágil), porque basta un listener olvidado para seguir expuesto y porque parte de la suposición de que todos los exploits viables dependen de MPTCP.

John Haxby apuntó en la misma lista, el 30 de octubre, la alternativa a nivel de sistema. Desactivar MPTCP en el kernel rompe los programas que lo exijan, pero cierra el vector de golpe:

sysctl -w net.mptcp.enabled=0
echo 'net.mptcp.enabled = 0' > /etc/sysctl.d/99-cve-2026-98432.conf

En el issue 82717 de Go, abierto el 29 de octubre para pedir que MPTCP deje de estar activo por defecto, el mantenedor de Go que firma como neild sugirió, sin haberlo confirmado, descartar los paquetes TCP IPv4 que lleven opciones IP, ya que la carrera arranca con una SYN que las trae. El aviso de golang-announce lo deja igual de claro: «the underlying bug is not specific to MPTCP» (el fallo de fondo no es específico de MPTCP). Esta regla de nftables, pensada para una tabla inet filter con cadena input ya creada, cuenta y descarta las SYN IPv4 cuya cabecera supera los 20 bytes, que es la señal de que transporta opciones:

nft add rule inet filter input ip hdrlength gt 5 tcp flags syn / syn,ack counter drop

Hay que tener en cuenta que algunos equipos de red y herramientas de diagnóstico usan Record Route o Timestamp, así que conviene dejar la regla en modo contador unos días antes de pasar a drop en producción. La guía de comandos Linux para ciberseguridad del blog repasa el resto de herramientas con las que comprobar qué escucha en un servidor.

Con las mitigaciones puestas, el orden de trabajo queda así:

1. Actualiza el kernel donde ya exista paquete: Debian trixie a 6.12.113-1, bookworm a 6.1.190-1 o 6.12.113-1~deb12u1, Oracle UEK con las ELSA del 16 de octubre, SUSE con los avisos del 29 y Amazon Linux 2023 a kernel6.12 6.12.113-138.209, y reinicia.
2. En Ubuntu 22.04, 24.04, 26.04 y 26.10 y en RHEL 8, 9 y 10, aplica net.mptcp.enabled=0 o GODEBUG=multipathtcp=0 en los servicios Go, y programa la ventana de reinicio para el día que Canonical y Red Hat publiquen las versiones que ya tienen asignadas.
3. Si compilas kernel propio o usas una rama sin soporte, aplica el parche completo de la versión estable correspondiente. El equipo CVE del kernel es tajante: «Cherry-picking individual commits is not recommended or supported by the Linux kernel community at all» (extraer commits sueltos no está recomendado ni lo soporta la comunidad del kernel).
4. Revisa en los registros del kernel los mensajes de skb_under_panic() y los oops en ip_options_build(), que son el rastro que deja un intento fallido según la descripción del CNA. Un servidor que se reinicia solo tras una racha de SYN con opciones merece investigación.
5. Si detectas actividad sospechosa, avisa a INCIBE-CERT (empresas y particulares) o al CCN-CERT (administración pública) y conserva las capturas de tráfico.

Para situar cada decisión de las distribuciones, estas son las fechas que ordenan la historia hasta hoy:

Un exploit de 53 minutos escrito por un modelo y el precedente de Fortinet

Es la segunda vez en una semana que una noticia de este blog gira en torno a vulnerabilidades encontradas con modelos de IA. El 26 de octubre contamos que Fortinet corrigió fallos hallados con modelos de frontera sin decir cuáles eran, y esta misma mañana publicamos el caso de la extensión de Claude Code con backdoor en Cursor, en el que Anthropic era la perjudicada. Aquí Anthropic es quien encontró el fallo y quien eligió contarlo con detalle, pero con una omisión relevante para los defensores: no sabemos en qué kernel ni con qué configuración funcionó la cadena.

Esa omisión no es un descuido. La política de divulgación que describe el informe da 90 días a los desarrolladores para parchear y otros 45 antes de publicar detalles que vayan más allá del aviso, y el reloj de este CVE empezó el 15 de octubre. Mientras tanto, lo que tenemos es una descripción técnica suficiente para que un equipo con experiencia en explotación del kernel reproduzca el trabajo, y el aviso de Anthropic de que lo que antes hacían unos pocos especialistas ahora lo hace un modelo con poca intervención humana.

La parte que nos parece más incómoda es el reparto de responsabilidades. El kernel cerró el fallo en cuatro días y Debian lo empaquetó en once. Canonical y Red Hat, que sostienen la mayor parte de los servidores Linux de las empresas españolas, llevan quince días con el CVE publicado y una puntuación de 9,8 encima de la mesa, y su calendario de kernels sigue siendo el de siempre. Red Hat tardó hasta el 30 de octubre en subir su propia clasificación a Critical. Nuestra lectura es que la discusión sobre si la complejidad es Low o High ha servido de justificación para no acelerar, y que la demostración de Anthropic, con todas sus lagunas, ha dejado esa justificación sin base. Lo mismo nos dijo el kernel la semana pasada con Fragnesia, el fallo que CISA incluyó en KEV cuando ya se encadenaba contra firewalls Palo Alto en producción.

Si administras servidores Ubuntu o RHEL expuestos a internet, la pregunta de hoy es qué listeners MPTCP tienes abiertos mientras llega el paquete. Una salida vacía de ss -Mltnp es la mejor noticia que puedes recibir esta tarde.