CVE-2026-98432, fallo TCP de Linux: proteja sus servidores

¿Qué es CVE-2026-98432?

CVE-2026-98432 es una vulnerabilidad del kernel de Linux, el núcleo de los sistemas operativos Linux. Su título oficial es ipv4: free inet_opt and ireq_opt after an RCU grace period ^[1]. El equipo de CVE del kernel de Linux la asignó y publicó el registro el 15 de octubre de 2026 ^[1]. El registro le otorga una puntuación base CVSS 3.1 de 9.8, calificada como crítica ^[1].

La falla es un use-after-free (uso después de liberar): un programa sigue usando una porción de memoria después de haberla liberado, por lo que esa memoria puede contener ya otros datos. En este caso, se encuentra en el código que gestiona las solicitudes entrantes de conexión TCP sobre IPv4 ^[10]. El vector CVSS es AV:N/AC:L/PR:N/UI:N. Esto significa que el ataque funciona a través de la red, tiene baja complejidad y no requiere privilegios ni interacción del usuario ^[1].

El error existe desde Linux 4.4, donde llegó con el commit 079096f103fa ^[2]. Una corrección escrita por Eric Dumazet se incorporó el 5 de octubre de 2026 y ya está en el kernel principal (mainline) ^[3]. Se ha portado a las ramas estables con mantenimiento ^[2][4].

¿Qué sistemas afecta?

Red Hat señala que la falla afecta a cualquier sistema que ejecute un kernel vulnerable con la red TCP sobre IPv4 habilitada. Los sistemas que aceptan conexiones TCP entrantes son los más expuestos de forma directa ^[6]. AlmaLinux recomienda considerar expuesto cualquier sistema que acepte conexiones TCP sobre IPv4 desde redes no confiables ^[10]. IPv6 no se ve afectado por el problema principal ^[2].

¿Cómo funciona la vulnerabilidad?

Una conexión TCP comienza con un handshake (negociación inicial). El cliente envía un paquete SYN, el servidor responde con un SYN-ACK y el cliente confirma. Un SYN puede incluir opciones de IPv4, que son campos adicionales opcionales en la cabecera IP. Record Route y Timestamp son dos ejemplos ^[1].

Según la descripción del kernel, la función tcp_v4_syn_recv_sock() entrega las opciones guardadas al nuevo socket hijo sin copiarlas ^[2]. Mientras tanto, otro núcleo de la CPU puede procesar un SYN retransmitido para la misma solicitud y construir un SYN-ACK que lee esas opciones ^[2]. Nada impide que el socket hijo se libere mientras el SYN-ACK todavía se está construyendo. Sus opciones se liberan con un simple kfree(), de modo que el kernel lee memoria liberada en ip_options_build() ^[2].

Existe una segunda condición de carrera similar cuando está activada la migración de sockets de solicitud, ya sea mediante net.ipv4.tcp_migrate_req=1 o mediante un programa BPF de reuseport ^[2]. La corrección hace que ambas rutas de liberación esperen un periodo de gracia de RCU, usando kfree_rcu() en inet_sock_destruct() y tcp_v4_reqsk_destructor() ^[2]. RCU (read-copy-update, lectura-copia-actualización) es una técnica del kernel que retrasa la liberación de memoria hasta que ningún lector pueda seguir usándola.

¿Qué podría hacer un atacante con ella?

Las notas de puntuación del registro CVE describen tres impactos ^[1]:

• Divulgación de información: otros datos pueden reutilizar la memoria liberada, y su contenido puede copiarse en el SYN-ACK que se devuelve al atacante ^[1].
• Corrupción de memoria: longitudes y desplazamientos obsoletos pueden dirigir escrituras del kernel fuera de los límites, con posible corrupción del flujo de control ^[1].
• Bloqueos: un valor de longitud reutilizado puede provocar un kernel panic, y las escrituras erráticas también pueden hacer que el kernel se bloquee ^[1].

Red Hat añade que ejecutar código de forma fiable mediante este error, que depende de la sincronización, requiere un control preciso del heap. Aun así, lo califica como crítico porque no tiene requisitos previos de red y puede causar una inestabilidad grave ^[7].

¿Qué reveló Anthropic y qué papel desempeña MPTCP?

El 27 de octubre de 2026, el Frontier Red Team de Anthropic publicó un informe sobre vulnerabilidades que encontró con modelos Claude ^[4][11]. Sobre CVE-2026-98432, afirma que el equipo desarrolló un exploit que permite a un atacante remoto ejecutar comandos arbitrarios como root en servidores Linux con un listener de Multipath TCP (MPTCP), sin credenciales ni interacción del usuario ^[4]. MPTCP es una extensión de TCP que permite que una sola conexión utilice varias rutas de red a la vez.

Anthropic describe dos etapas. Primero, el exploit filtra un puntero del kernel para eludir KASLR, la aleatorización de direcciones del kernel. Después, sobrescribe un puntero de callback para que el kernel ejecute como root un comando elegido por el atacante ^[4]. Perder la carrera solo hace fallar el handshake y no bloquea el sistema, por lo que un atacante puede seguir reintentando ^[4]. En la prueba de concepto de Anthropic, filtrar un puntero del kernel llevó 48 minutos, y la ejecución de comandos, otros cinco minutos ^[4].

¿Es necesario MPTCP?

No, según los proveedores que lo han evaluado. Red Hat afirma que MPTCP no es una condición necesaria para esta falla y que los sistemas con MPTCP desactivado siguen afectados ^[6]. El equipo de seguridad de Go señala que el exploit demostrado necesita un listener de MPTCP, pero que el error de fondo no es exclusivo de MPTCP ^[5]. Go es relevante aquí porque, desde Go 1.24, los programas en Go activan MPTCP por defecto en los sockets de escucha en Linux ^[5].

Según Akamai, Anthropic no ha publicado su exploit de root, y el 2 de noviembre de 2026 Akamai declaró que no tenía conocimiento de un exploit público funcional ^[11].

¿Qué versiones del kernel y qué distribuciones están corregidas?

El equipo de CVE del kernel enumera estas correcciones upstream: 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 y la mainline 7.3 ^[2]. Sin embargo, la mayoría de las personas usan un kernel compilado por su distribución, que emplea su propia numeración de versiones. Consulte el aviso de seguridad de su distribución en lugar de comparar los números upstream.

Estado a 3 de noviembre de 2026:

• Red Hat Enterprise Linux: el 1 de noviembre de 2026 se publicaron kernels corregidos para RHEL 8, 9 y 10. RHEL 6 y 7 figuran como no afectados. El kernel de tiempo real de RHEL 9 y las imágenes de nodo de OpenShift siguen figurando como afectados ^[7].
• Ubuntu: Ubuntu califica el problema como crítico. Su sistema de seguimiento muestra 26.10, 26.04 LTS, 24.04 LTS y 22.04 LTS como vulnerables, con correcciones en proceso; 20.04, 18.04 y 16.04 también figuran como vulnerables, y 14.04 como no afectada ^[8].
• Debian: hay correcciones disponibles para Debian 12 bookworm (linux 6.1.190-1 y linux-6.12 6.12.113-1~deb12u1) y Debian 13 trixie (linux 6.12.113-1), así como para unstable ^[9].
• AlmaLinux: los kernels corregidos para AlmaLinux 8, 9 y 10 están en los repositorios de producción ^[10].
• Otras: Akamai informó que SUSE, Oracle Linux y Amazon Linux 2023 habían publicado kernels corregidos para algunas versiones antes del 30 de octubre de 2026 ^[11].

¿Y los teléfonos Android?

Android usa el kernel de Linux, pero el Boletín de Seguridad de Android publicado el 2 de noviembre de 2026 no incluye CVE-2026-98432 ^[13]. Los usuarios de teléfonos deben instalar las actualizaciones de seguridad a medida que su fabricante las publique.

¿Cómo comprobar si un servidor es vulnerable?

1. Identifique el kernel en ejecución. Ejecute uname -r. Una corrección solo cuenta cuando la máquina se ha reiniciado con el nuevo kernel. AlmaLinux indica a los usuarios que reinicien y confirmen la versión con uname -r ^[10].
2. Compare con el sistema de seguimiento de su proveedor. Busque CVE-2026-98432 en la página de seguridad de su distribución. Red Hat ^[7], Ubuntu ^[8], Debian ^[9] y AlmaLinux ^[10] indican cada uno las versiones de paquete que contienen la corrección.
3. Revise MPTCP. sysctl net.mptcp.enabled muestra si MPTCP está activado. sudo ss -lnMp enumera los listeners de MPTCP y los procesos a los que pertenecen ^[10]. Akamai también sugiere revisar net.ipv4.tcp_migrate_req ^[11].
4. Busque servicios escritos en Go. Los programas compilados con Go 1.24 o posterior abren listeners de MPTCP por defecto en Linux ^[5]. Por lo tanto, cualquier servicio en Go que ejecute podría exponer la ruta que explotó Anthropic.
5. Revise los productos construidos encima. Red Hat advierte que cualquier producto basado en el kernel de RHEL, incluidos OpenShift, OpenStack y Red Hat Virtualization, también puede verse afectado ^[6].

¿Cómo corregir o mitigar CVE-2026-98432?

La verdadera solución es un kernel parcheado. Red Hat considera que aplicar las actualizaciones del kernel es la única solución completa ^[6], y el equipo de seguridad de Go afirma que la mejor corrección es actualizar a un kernel parcheado ^[5]. Instale la actualización del kernel de su distribución, reinicie y confirme la versión en ejecución.

¿Qué puede hacer antes de que llegue un parche?

• Descarte los paquetes TCP con opciones de IPv4. Red Hat publica, y el sistema de seguimiento de Ubuntu recoge como solución alternativa aportada por usuarios, una regla de nftables que descarta los paquetes TCP sobre IPv4 entrantes cuya cabecera IP supera los 20 bytes básicos, es decir, los paquetes que llevan opciones (ip hdrlength > 5) ^[6][8]. Las opciones TCP normales, como las marcas de tiempo y el escalado de ventana, van en la cabecera TCP y no se ven afectadas ^[8]. Ambos proveedores indican que la regla reduce el riesgo, pero no puede impedir por completo la explotación ^[6][8].
• Conozca los límites de la regla. AlmaLinux señala que su versión no se conserva tras un reinicio, que el tráfico entre contenedores del mismo host puede eludirla, que también descarta paquetes reenviados en hosts que actúan como enrutadores y que deja sin funcionar las redes que dependen de etiquetas CIPSO/NetLabel ^[10]. Ubuntu señala que los contenedores con red independiente necesitan que la regla se aplique por separado ^[8].
• Desactive MPTCP si no lo necesita. Configurar net.mptcp.enabled=0 desactiva MPTCP en todo el sistema ^[10]. Akamai también sugiere configurar net.ipv4.tcp_migrate_req=0 ^[11]. Akamai advierte que desactivar solo MPTCP no impide la explotación; únicamente reduce la probabilidad de desencadenar la condición de carrera ^[11]. Los programas en Go también pueden excluirse con GODEBUG=multipathtcp=0, pero el equipo de Go considera frágiles las exclusiones programa por programa ^[5].
• Filtre en el perímetro. Para OpenShift, Red Hat señala que las reglas en un nodo no filtran el tráfico entre pods, mientras que filtrar en el límite de la red, delante del clúster, evita esa limitación ^[6].

¿Sirve init_on_free=1?

Una publicación en oss-security sugirió la opción de arranque init_on_free=1 como medida provisional adicional. Un miembro del equipo del kernel de CIQ respondió que no mitiga esta CVE de forma significativa y que no debería tener peso en los avisos de seguridad ^[12]. Trátela como un endurecimiento general, no como una mitigación para este error.

¿Se está explotando CVE-2026-98432?

A 3 de noviembre de 2026, CVE-2026-98432 no aparece en el catálogo de vulnerabilidades explotadas conocidas (KEV) de la CISA, la lista del gobierno de Estados Unidos de fallas con explotación confirmada en el mundo real ^[14]. Akamai declaró el 2 de noviembre de 2026 que no tenía conocimiento de un exploit público funcional ^[11]. Eso no prueba que nadie esté explotando el error. Se ha demostrado que existe un exploit fiable ^[4], y los detalles técnicos son públicos en la corrección del kernel ^[3].

La valoración de la gravedad también cambió con el tiempo. La CVE se publicó por primera vez el 15 de octubre de 2026 ^[1]. La atención general llegó tras el informe de Anthropic del 27 de octubre ^[4][11]. Entre el 29 de octubre y el 2 de noviembre siguieron los boletines de los proveedores con mitigaciones provisionales ^[5][6][10]. Los administradores que solo leyeron por encima el registro original pueden haber pasado por alto las indicaciones posteriores.

¿Qué pasará a continuación?

Red Hat describe su investigación como en curso y afirma que su boletín se actualizará a medida que surja nueva información ^[6]. Es previsible que los paquetes pendientes, como el kernel de tiempo real de RHEL 9 y las imágenes de OpenShift ^[7] y los kernels de Ubuntu aún en proceso ^[8], reciban correcciones en los próximos días o semanas. Consulte los sistemas de seguimiento de los proveedores en lugar de los resúmenes de prensa, porque estas páginas cambiaron varias veces en las primeras semanas.

La corrección del kernel también deja abierto un problema relacionado. La descripción del kernel indica que tcp_v6_reqsk_destructor() de IPv6 tiene el mismo problema de migración con opciones establecidas únicamente por CALIPSO, y que esto se resolverá en un parche aparte ^[2]. Según la política de divulgación coordinada de Anthropic, se conceden 90 días para aplicar parches y otros 45 días antes de comentar detalles que vayan más allá del aviso público ^[4]. Por lo tanto, más adelante podrían conocerse más detalles técnicos.

Esta es información técnica general y no sustituye el aviso de seguridad de su proveedor ni el proceso de respuesta a incidentes de su organización.