El equipo de seguridad de Anthropic ha creado un exploit funcional para una vulnerabilidad crítica del kernel de Linux que permite a atacantes sin autenticación ejecutar comandos con privilegios de root de manera remota en servidores que mantienen listeners de Multipath TCP (MPTCP). El fallo, identificado como CVE-2026-98432, también afecta a conexiones TCP convencionales, aunque la ejecución remota de código no se ha demostrado públicamente en equipos que no tengan habilitado un listener MPTCP.
Qué es MPTCP y por qué amplía el riesgo
Multipath TCP es una extensión de TCP que permite que una única conexión utilice varias rutas de red simultáneamente para mejorar el rendimiento y la fiabilidad. Se emplea habitualmente en entornos donde los dispositivos disponen de varias conexiones, como redes Wi-Fi y celulares. Aunque MPTCP no suele estar activado por defecto en las aplicaciones, algunos programas lo habilitan automáticamente: desde Go 1.24, este lenguaje activa MPTCP por defecto para los listeners TCP en Linux siempre que el kernel lo soporte, de modo que ciertos servicios de red basados en Go pueden exponer listeners MPTCP sin que los administradores lo sepan.
Naturaleza del fallo y puntuaciones divergentes
CVE-2026-98432 es una vulnerabilidad de use-after-free en el código de red TCP IPv4 del kernel, con una puntuación de severidad de 9,8 sobre 10 otorgada por el equipo CVE del kernel de Linux. Afecta a kernels desde la versión 4.4, incluidas distribuciones muy extendidas como Ubuntu, Red Hat Enterprise Linux (RHEL) y Rocky Linux. Según el aviso del kernel, el problema deriva de una condición de carrera en el tratamiento de solicitudes de conexión TCP que puede provocar el use-after-free.
tcp_v4_syn_recv_sock() transfiere la propiedad de ireq->ireq_opt al socket hijo (newinet->inet_opt) sin copiarla. Otra CPU puede procesar simultáneamente un SYN retransmitido para el mismo request socket y enviar un SYNACK desde tcp_check_req(). tcp_v4_send_synack() e inet_csk_route_req() leen ireq->ireq_opt solo bajo rcu_read_lock(), y después ip_build_and_send_pkt() e ip_options_build() leen opt->optlen dos veces.
Un problema similar puede producirse durante la migración de request sockets TCP cuando está habilitado net.ipv4.tcp_migrate_req o se utiliza un programa BPF_SK_REUSEPORT_SELECT_OR_MIGRATE. Aunque desencadenar la vulnerabilidad no requiere autenticación, Red Hat señala que explotar la condición de carrera es más complejo que simplemente enviar un paquete de red malicioso. La compañía la clasifica como un posible problema de denegación de servicio que podría provocar un fallo del kernel y le asigna una severidad menor, de 5,9, debido a la complejidad de la explotación.
Demostración de ejecución remota de código
No obstante, los investigadores de Anthropic demostraron que la vulnerabilidad puede explotarse para ejecución remota de código en condiciones específicas. Según su informe, un modelo de IA Claude aún no publicado desarrolló un exploit que eludió la aleatorización del espacio de direcciones del kernel (KASLR) y ejecutó comandos arbitrarios como root en un servidor Linux con un listener MPTCP. El exploit tardó unos 53 minutos en lograr la ejecución remota de código con privilegios de root, lo que demuestra que el fallo puede ir más allá de los ataques de denegación de servicio.
Parches y estado de las distribuciones
La vulnerabilidad se corrigió en el kernel de Linux upstream y se retroportó a las ramas de kernel mantenidas, pero las actualizaciones de seguridad aún no se han distribuido a todas las distribuciones afectadas. Según el rastreador de seguridad de Canonical, Ubuntu 22.04 LTS, 24.04 LTS, 26.04 LTS y 26.10 seguían vulnerables a 30 de octubre, con correcciones del kernel en curso. Red Hat también incluye RHEL 8, 9 y 10 como afectados, con arreglos previstos para futuras actualizaciones; RHEL 7 no está afectado porque su kernel no contiene el código vulnerable.
CIQ, proveedor de soporte de Rocky Linux, confirma que Rocky Linux 8, 9 y 10 también están afectados y compartió protecciones temporales de firewall para los sistemas vulnerables. Según el rastreador de seguridad de Debian, el fallo se corrigió en la versión 6.1.190-1 del paquete del kernel para Debian 12 (Bookworm) y en la 6.12.113-1 para Debian 13 (Trixie); también hay paquetes corregidos para Debian testing y unstable. Otros proveedores, como Oracle Linux, Amazon Linux y SUSE, han publicado asimismo correcciones para algunas versiones de kernel afectadas. macOS no se ve afectado, ya que utiliza el kernel XNU de Apple en lugar del kernel de Linux.
Recomendaciones de mitigación
Se recomienda a los administradores revisar los avisos de seguridad de su distribución e instalar los paquetes de kernel actualizados en cuanto estén disponibles. En los sistemas donde aún no haya parches, restringir el acceso a redes o direcciones IP de confianza puede reducir el riesgo. CIQ aconseja además bloquear temporalmente los paquetes TCP IPv4 que contengan opciones IP antes de que lleguen al código vulnerable de procesamiento TCP, y compartió ejemplos de reglas nftables para bloquear ese tráfico.
La empresa advierte de que desactivar MPTCP por sí solo no basta, porque la vulnerabilidad subyacente puede seguir desencadenándose mediante tráfico TCP normal. Por el momento no hay informes confirmados de explotación de CVE-2026-98432 en entornos reales.
- Revisar los avisos de seguridad de la distribución e instalar los kernels actualizados.
- Restringir el acceso a redes o direcciones IP de confianza mientras no haya parches.
- Bloquear temporalmente los paquetes TCP IPv4 con opciones IP mediante reglas nftables.
- No basta con desactivar MPTCP: el tráfico TCP normal también puede desencadenar el fallo.
Deja una respuesta