CVE-2026-98432 es una falla en la forma en que el kernel de Linux acepta las solicitudes de conexión TCP. Permite que un atacante remoto, sin contraseña, haga caer el servidor o corrompa la memoria del kernel. El equipo de CVE del kernel de Linux le da una puntuación de 9,8 sobre 10, y Anthropic afirma que su modelo Claude escribió un exploit que da a un atacante acceso root en servidores que aceptan conexiones MPTCP. La corrección ya está en el kernel oficial y Debian la ha publicado, pero al 30 de octubre de 2026 Ubuntu la marca como "work in progress" (en curso) para 22.04, 24.04 y 26.04, y Red Hat indica que RHEL 8, 9 y 10 están afectados y sin actualización. Hasta que llegue la actualización: desactive MPTCP si no lo necesita, bloquee los paquetes IPv4 que llevan opciones IP, restrinja quién puede llegar a sus servidores y programe el reinicio.

¿Qué es CVE-2026-98432 y por qué le importa a su empresa?

Según el registro oficial de CVE, la falla está en el momento en que se completa un handshake TCP sobre IPv4: el kernel entrega a la nueva conexión las opciones IP guardadas con la solicitud de conexión sin copiarlas, mientras otra CPU puede, en ese mismo instante, procesar una solicitud duplicada y construir una respuesta con esas opciones. Si el kernel libera antes esa memoria, después la lee ya liberada, un error conocido como use-after-free. La falla existe desde el kernel 4.4. El equipo de CVE del kernel la publicó el 15 de octubre de 2026 y le dio 9,8 sobre 10 porque se puede alcanzar por la red, durante el handshake y antes de cualquier inicio de sesión, sin interacción del usuario.

En una publicación del 27 de octubre, Anthropic dijo que Claude escribió un exploit que permite a un atacante remoto sin credenciales ejecutar comandos como root en servidores Linux que aceptan conexiones MPTCP, o TCP multitrayecto. En su prueba, el exploit tardó 48 minutos en filtrar una dirección de la memoria del kernel y luego 5 minutos en llegar a la ejecución de comandos. Peor aún, un intento fallido no hace caer el servidor; solo falla esa conexión, así que un atacante puede seguir intentándolo sin que nadie lo note. Anthropic no publicó el exploit en sí.

Red Hat describe el impacto principal como una caída del servidor y una denegación de servicio, con posible corrupción de memoria. En la versión del 30 de octubre del catálogo de vulnerabilidades explotadas conocidas de CISA, la falla todavía no figuraba.

¿Ha llegado ya una actualización a su distribución?

Este es el estado que mostraba la página oficial de cada distribución el 30 de octubre de 2026:

DistribuciónEstado
Ubuntu 22.04, 24.04, 26.04 y 26.10Vulnerable, corrección "work in progress" (en curso); para 24.04 en el kernel 6.8.0-149 (página de Ubuntu)
Ubuntu 16.04, 18.04 y 20.04Vulnerable
Red Hat Enterprise Linux 8, 9 y 10Afectado, sin actualización publicada (página de Red Hat)
Red Hat Enterprise Linux 6 y 7No afectado
Debian 12 y 13Corregido en 6.1.190-1 y 6.12.113-1 (rastreador de Debian)

En el kernel oficial, la corrección llegó en las versiones 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 y 7.3. Pero la mayoría de los servidores ejecutan el kernel de su distribución, así que lo que cuenta es la página de su distribución, no el número de versión oficial.

¿Cómo saber si un servidor está expuesto?

Ejecute estos comandos en cada servidor Linux que acepte conexiones desde internet:

uname -r
cat /proc/sys/net/mptcp/enabled
ss -Mln
cat /proc/sys/net/ipv4/tcp_migrate_req
  • El primero muestra la versión del kernel; compárela con la página de su distribución. En Ubuntu 24.04, por ejemplo, todas las versiones disponibles hoy están sin corregir.
  • Un valor de 1 en el segundo significa que MPTCP está activado, que es lo predeterminado según la documentación del kernel.
  • El tercero enumera los servicios que aceptan conexiones MPTCP. Cualquier servicio que aparezca es el tipo de objetivo que explotó Anthropic. Atención a los programas escritos en Go: según las notas de la versión Go 1.24, sus listeners ahora usan MPTCP por defecto donde está disponible.
  • El cuarto debería mostrar 0; según el registro CVE, la segunda vía de la falla solo funciona cuando vale 1.

La solución temporal hasta que llegue la actualización: 5 pasos

  1. Si su distribución ya tiene la corrección, instálela ahora y reinicie. En Debian 12 y 13, por ejemplo: 
    sudo apt update && sudo apt upgrade
sudo reboot
    El nuevo kernel no le protege hasta que el servidor lo esté ejecutando.
  2. Desactive MPTCP si ningún servicio lo necesita. Así cierra el tipo de objetivo que explotó Anthropic: 
    sudo sysctl -w net.mptcp.enabled=0
echo "net.mptcp.enabled = 0" | sudo tee /etc/sysctl.d/99-disable-mptcp.conf
    El primer comando aplica el ajuste al instante; el segundo lo conserva tras un reinicio. La documentación del kernel indica que el ajuste es por espacio de nombres de red, así que aplíquelo también dentro de los contenedores. Los programas en Go vuelven automáticamente a TCP normal cuando MPTCP no está disponible. Pero ni Anthropic ni ninguna distribución dicen que desactivarlo elimine la falla en sí, así que reduce el riesgo en lugar de curarlo.
  3. Bloquee los paquetes TCP que llevan opciones de IPv4. El escenario de puntuación del registro CVE supone un atacante que envía una solicitud de conexión con la opción Record Route o Timestamp de IPv4, y el tráfico normal de web, correo y SSH no necesita esas opciones. Pida a su administrador de red una regla de cortafuegos que descarte los paquetes TCP entrantes cuya cabecera IPv4 supere los 20 bytes, y pruébela primero en un solo servidor. Ninguna distribución dice que esto bloquee la falla, pero elimina la condición que supone la puntuación.
  4. Restrinja quién puede llegar a sus servidores. La falla necesita un puerto TCP abierto que acepte conexiones, así que cierre todos los puertos que no necesite y deje SSH y los paneles de administración accesibles solo desde direcciones IP concretas o a través de una VPN. Si el sitio está detrás de un intermediario como una CDN, haga que el servidor de origen acepte conexiones solo desde las direcciones de ese servicio.
  5. Prepare la actualización antes de que llegue. Siga las páginas de Ubuntu y Red Hat sobre este CVE, apruebe de antemano la actualización del kernel y fije una ventana de reinicio, para que la corrección se instale el mismo día en que se publique. Vigile el registro del kernel por si aparecen caídas que mencionen ip_options_build: 
    sudo journalctl -k | grep -i ip_options_build
    Aun así, un registro tranquilo no significa que esté a salvo, porque un intento fallido no hace caer el servidor.

¿Y si sus servidores están con un proveedor de alojamiento?

En el alojamiento compartido y en los servicios gestionados, el kernel es del proveedor, no suyo. Hágale tres preguntas: qué distribución y qué versión del kernel usan sus servidores, cuándo instalará la corrección y qué está haciendo para reducir el riesgo mientras tanto. Un servidor privado virtual (VPS) suele dejar el kernel en sus manos, así que aplique usted mismo los pasos anteriores.

La visión de Origami

Como contamos en nuestro artículo sobre las vulnerabilidades de PHP, cuando la actualización oficial se retrasa, los pasos temporales son lo que protege a los servidores en los primeros días. Eso sí, reducen el riesgo; la única cura es el kernel corregido tras un reinicio. En Origami podemos revisar sus servidores Linux, aplicar los pasos temporales sin interrumpir sus servicios e instalar la corrección en cuanto se publique. Contáctenos.

Puntos clave

  • CVE-2026-98432 es una falla del kernel de Linux con una puntuación de 9,8 sobre 10 según el equipo del kernel, que ataca el servidor a distancia durante el handshake TCP, antes de cualquier inicio de sesión.
  • Debian ya publicó la corrección; Ubuntu y Red Hat aún no lo habían hecho al 30 de octubre de 2026.
  • Hasta que lo hagan: desactive MPTCP si no lo necesita, bloquee los paquetes TCP con opciones de IPv4 y cierre los puertos que no use.
  • Instale el kernel corregido en cuanto se publique y reinicie; los pasos temporales no lo sustituyen.

Fuentes