Una vulnerabilidad crítica del núcleo de Linux relacionada con el protocolo TCP puede permitir la ejecución remota de código (CVE-2026-98432)

TL;DR

CVE-2026-98432 es una vulnerabilidad relacionada con la forma en que el núcleo de Linux establece conexiones TCP IPv4, presente en el núcleo 4.4 y versiones posteriores. El propio equipo CVE del núcleo le otorga una puntuación de 9,8 sobre 10. Anthropic informa de que un modelo de investigación de Claude aún no publicado creó un exploit que permite a un atacante remoto obtener privilegios de root en un servidor Linux con un listener MPTCP (Multipath TCP), sin necesidad de credenciales ni interacción por parte del usuario. AWS confirma que, en condiciones específicas, un atacante remoto no autenticado podría lograr la ejecución remota de código. A fecha de 2 de noviembre, ningún proveedor ni CERT había informado de ataques en el mundo real y el CVE no figuraba en el catálogo de vulnerabilidades explotadas conocidas de la CISA. Desde entonces, el investigador Marcus Hutchins ha informado de lo que parecen ser actores maliciosos que escanean Internet en busca de servidores con MPTCP habilitado.

Cómo solucionar la vulnerabilidad CVE-2026-98432

Instala un kernel parcheado y reinicia el sistema. AWS afirma que esta es la única solución completa y señala que un «livepatch» también resuelve el problema.

Identifica primero todas las máquinas virtuales afectadas. Incluye los hosts que se te hayan pasado por alto y los nodos que se encuentran bajo tus contenedores. La función «Máquinas virtuales» de Aikido señala aquellas que ejecutan un kernel afectado.

Amazon Linux. Hay paquetes de kernel parcheados disponibles para Amazon Linux 2 y 2023 con los kernels 4.14, 5.4, 5.10, 5.15, 6.1, 6.12 y 6.18.

• Amazon Linux 2: sudo yum update kernel && sudo reboot
• Amazon Linux 2023: sudo dnf update kernel --releasever=latest && sudo reboot

Kubernetes, ECS y otros servicios gestionados de AWS

• EKS: actualiza los grupos de nodos gestionados, los nodos autogestionados y los nodos Karpenter a la versión v20261031 de la AMI o posterior. El modo automático de EKS sustituye los nodos automáticamente.
• ECS en EC2: actualiza el núcleo y reinicia el sistema, o sustituye las instancias por la AMI optimizada para ECS, versión 20261031.
• Fargate: las tareas nuevas que se inicien a partir del 1 de noviembre de 2026 a las 6:00 a. m. PDT utilizarán la plataforma actualizada. Las tareas existentes se retirarán según la configuración de retirada de tareas que hayas establecido, aunque también puedes sustituirlas antes.
• Bottlerocket: se esperaba que las AMI actualizadas estuvieran disponibles a partir del 2 de noviembre.

Otras distribuciones. Consulta el sistema de seguimiento de tu proveedor, ya que el estado cambia a diario.

• Ubuntu: la versión 26.10 se ha corregido en 7.3.0-10.10. Las correcciones para 22.04 (5.15.0-203.213), 24.04 (6.8.0-149.149) y 26.04 (7.0.0-43.43) se encuentran en el repositorio de pruebas «-proposed», del que apt no instala por defecto, por lo que hay que habilitarlo e instalar el núcleo explícitamente utilizando los comandos que se indican en la publicación de Canonical. Las versiones 16.04, 18.04 y 20.04 aún tienen una corrección pendiente, y los núcleos para la nube, FIPS y en tiempo real tienen sus propias versiones en la página de CVE de Ubuntu.
• Red Hat: se distribuyeron kernels corregidos el 1 de noviembre para RHEL 8 (RHSA-2026:93414), RHEL 9 (RHSA-2026:93412) y RHEL 10 (RHSA-2026:93413), junto con avisos adicionales para las líneas EUS, SAP y NVIDIA. A fecha de 3 de noviembre, las imágenes «kernel-rt» de RHEL 9 y las de OpenShift 4 y 5 CoreOS seguían figurando como afectadas, mientras que RHEL 6 y 7 no se ven afectadas.
• Debian, Oracle Linux y SUSE: se han distribuido paquetes corregidos para, al menos, algunos núcleos, según The Hacker News.

Compilar tu propio núcleo. La corrección del desarrollador original se encuentra 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 de Linux. El equipo de CVE del núcleo recomienda actualizar al último núcleo estable en lugar de seleccionar solo el parche.

Cómo ayuda el aikido

El análisis de máquinas virtuales de Aikido ha detectado el CVE-2026-98432 en tus máquinas virtuales conectadas, con una gravedad base de 9,8. Aikido ajusta la gravedad de cada máquina virtual en función de su accesibilidad desde la red, así que utiliza la vista de accesibilidad para ver a qué máquinas virtuales puede acceder Internet y aplica los parches a esas primero.

Si aún no has conectado tus máquinas virtuales, ve a «Máquinas virtuales» en Aikido y selecciona «Conectar máquinas virtuales». Aikido es compatible con AWS, Azure y GCP.

La detección se basa en los avisos de los proveedores. En caso de que un proveedor aún no haya publicado un kernel corregido, un equipo puede ser vulnerable sin que aparezca como afectado, por lo que también debes consultar el sistema de seguimiento de tu distribución. Un equipo que haya instalado la actualización pero aún no se haya reiniciado puede aparecer como corregido, así que reinícialo primero.

Si todavía no puedes instalar el parche

Estos pasos reducen la vulnerabilidad. Ninguno de ellos soluciona el fallo, por lo que debes aplicar el parche y reiniciar el sistema tan pronto como tu proveedor publique un nuevo kernel. AWS indica que los dos primeros son medidas provisionales, mientras que Red Hat afirma que ninguna de las medidas de mitigación que ha analizado es fácil de implementar, adecuada para la mayoría de las instalaciones y estable. Si ejecutas un servidor Go que no está protegido por un equilibrador de carga, utiliza la configuración de Go que se indica a continuación.

1. Desactiva MPTCP. Establece net.mptcp.enabled=0. Para programas escritos en Go 1.24 o posterior, establece GODEBUG=multipathtcp=0. Esto es importante porque el exploit de Anthropic necesitaba un listener MPTCP, y Go 1.24 y versiones posteriores los solicitan por defecto cuando el kernel permite MPTCP. Se trata de una medida de control débil: el equipo de seguridad de Go considera que la desactivación por programa es poco fiable, ya que un solo listener de MPTCP que quede expuesto sigue dejando al sistema vulnerable. Al establecer net.mptcp.enabled=0, los sockets de MPTCP que ya estén abiertos permanecen activos, por lo que hay que reiniciar los servicios afectados posteriormente, según Marcus Hutchins. Para ver la lista de listeners de MPTCP, ejecuta sudo ss -Mlnp.
2. Descartar los paquetes IPv4 que contengan opciones IP. AWS proporciona esta regla: iptables -I INPUT 1 -m u32 --u32 '0>>24&0x0f=6:15' -j DROP. Esto es importante porque la vulnerabilidad radica en la forma en que el núcleo gestiona las opciones IP almacenadas con una conexión pendiente, y el ataque utiliza un paquete SYN que las transporta. En AWS Network Firewall, AWS publica una regla con estado equivalente que requiere un orden estricto de las reglas.
3. Coloca el servidor detrás de un equilibrador de carga independiente o de un servicio gestionado que cierre la conexión TCP antes de que el tráfico llegue al núcleo del sistema. Un proxy en el mismo servidor no cuenta. Actualiza las instancias que hay detrás de él de todos modos.

Cómo comprobar si la corrección ya está activa

Una actualización del núcleo solo surte efecto tras reiniciar el sistema, así que comprueba el núcleo que se está ejecutando, no el que está instalado.

uname -r

Compara el resultado con la versión corregida del núcleo que figura en el aviso de tu proveedor. Los proveedores adaptan las correcciones a versiones anteriores, por lo que debes utilizar su propia versión corregida en lugar de la del desarrollador original. Si sigue apareciendo la versión antigua, significa que el servidor no se ha reiniciado con el núcleo parcheado.

Repite este proceso en todas las máquinas virtuales, incluidas las que se te hayan olvidado y los nodos que se encuentran bajo tus contenedores.

Quiénes están afectados

Cualquier servidor Linux que ejecute el kernel 4.4 o posterior y cuente con un puerto TCP IPv4 al que un atacante pueda acceder. IPv6 no se ve afectado por la vulnerabilidad principal. En AWS, esto incluye las instancias EC2 y Lightsail autogestionadas, las instancias de contenedores ECS en EC2 y los nodos EKS. AWS Lambda no se ve afectado, ya que las funciones no exponen puertos TCP IPv4 públicos.

Lo que haya delante del presentador influye en tu exposición:

• AWS WAF, Application Load Balancer, Classic Load Balancer, los escuchadores TLS de Network Load Balancer, CloudFront y API Gateway. AWS afirma que, si se siguen las prácticas recomendadas, estos servicios no transmiten conexiones TCP procedentes de fuentes no fiables directamente a tus instancias, y está aplicando parches a la infraestructura subyacente. No obstante, sigue recomendando actualizar las instancias que se encuentran detrás de ellos en un plazo de 30 días.
• Escuchas TCP de Network Load Balancer y Global Accelerator. AWS recomienda a los clientes que actualicen la versión de su plataforma en cuanto estén disponibles las versiones con parches.
• Un proxy como nginx o HAProxy en tu propio servidor Linux. Esto no es un escudo. El núcleo de la máquina que acepta la conexión se encarga del protocolo de enlace TCP, por lo que el servidor proxy también necesita el parche.

En el caso de los contenedores, el núcleo que importa es el del nodo en el que se ejecutan.

¿Es grave?

Considera esto como urgente para cualquier servidor conectado a Internet. Hay tres aspectos que destacan:

• Se ha demostrado la existencia de un exploit de root remoto. El equipo Frontier Red Team de Anthropic afirma que, tras una indicación inicial, Claude escribió un exploit que ejecuta comandos como root en un servidor Linux con un listener de TCP multipath (MPTCP). En su prueba, la revelación de una dirección del kernel tardó 48 minutos y se necesitaron 5 minutos más para llegar a la ejecución de comandos.
• El atacante puede volver a intentarlo. Según Anthropic, una carrera perdida solo falla en ese único intercambio de datos y no provoca un fallo del sistema, por lo que un atacante decidido puede seguir intentándolo hasta que lo consiga.
• Esta condición previa puede ser más habitual de lo que parece. Una aplicación debe solicitar MPTCP al abrir un socket, y, según el equipo de seguridad de Go, desde la versión 1.24, los programas escritos en Go lo hacen de forma predeterminada para los sockets en los que están a la escucha. El núcleo también debe permitir MPTCP, y algunas distribuciones, como AlmaLinux y CloudLinux, lo incluyen desactivado de forma predeterminada. Cuando está activado, un servidor Go puede actuar como oyente sin que nadie lo haya seleccionado.

Aún quedan algunas cuestiones sin resolver. Anthropic no ha publicado el exploit, la versión del núcleo ni la configuración con la que realizó las pruebas, y el equipo del núcleo de CloudLinux afirma que no ha podido reproducir el problema. La vulnerabilidad se encuentra en el código TCP estándar de IPv4, y ni el registro CVE ni la corrección del núcleo mencionan MPTCP, por lo que el equipo de seguridad de Go señala que los sistemas que no cuenten con escuchas MPTCP podrían ser vulnerables a ataques similares. El boletín de Red Hat señala que MPTCP no es un requisito imprescindible para esta vulnerabilidad y que los nodos de OpenShift, en su configuración predeterminada —con MPTCP desactivado—, siguen siendo vulnerables. A fecha de 2 de noviembre, ningún proveedor ni CERT había informado de ataques en el mundo real. Marcus Hutchins informa de que, el 2 de noviembre, proxies residenciales y servidores VPN con sede en Rusia comenzaron a sondear el puerto 443 a través de MPTCP, lo que él sospecha que es un escaneo en busca de este CVE; además, su propio escaneo del 30 de octubre detectó unos 2,1 millones de servidores accesibles a través de MPTCP en ese puerto.

La mayoría de los proveedores le otorgan una puntuación más baja que el equipo del núcleo, ya que consideran que es más difícil ganar la carrera:

‍¿Qué es CVE-2026-98432?

En términos sencillos, el núcleo puede liberar un bloque de memoria mientras otra CPU todavía lo está leyendo. Según el equipo de CVE del núcleo, un atacante que controle la sincronización puede aprovechar esto para leer o corromper la memoria del núcleo, o bien provocar un fallo del sistema.

Durante un protocolo de enlace TCP, el cliente envía un paquete SYN y el servidor responde con un SYNACK. El núcleo conserva las opciones IP del SYN con un marcador de posición para la conexión semiabierta, denominado «solicitud» ( socket). En tcp_v4_syn_recv_sock(), el nuevo proceso hijo socket asume la propiedad de esas opciones sin copiarlas. Si otra CPU sigue creando un SYNACK para un SYN retransmitido, las opciones pueden liberarse mientras aún están en uso. Se trata de un «use-after-free», en este caso en ip_options_build().

Solicitar una migración de « socket » (net.ipv4.tcp_migrate_req=1, o un programa BPF «reuseport migrate») abre una vía similar. La corrección del desarrollador original sustituye las llamadas a «free» por «kfree_rcu()», que espera hasta que ninguna CPU pueda seguir leyendo la memoria. IPv6 evita el primer problema porque el núcleo copia las opciones para las conexiones IPv6. Existe un problema de migración similar para IPv6, pero solo se aplica cuando CALIPSO establece opciones de IPv6, y el núcleo lo está abordando en un parche independiente.

El error se introdujo en Linux 4.4. Los desarrolladores del núcleo aplicaron la corrección el 5 de octubre y el CVE se publicó el 15 de octubre. En la corrección del núcleo se reconoce a un investigador de Anthropic por haberlo notificado.