Un exploit desarrollado por investigadores de Anthropic consiguió ejecutar comandos de forma remota como root en un servidor Linux con un listener MPTCP. La vulnerabilidad, identificada como CVE-2026-98432, afecta al código de red IPv4 del kernel y puede activarse sin autenticación, aunque el ataque depende de condiciones específicas.
BleepingComputer informó el 30 de octubre de que un modelo de Claude aún no publicado desarrolló el exploit y logró eludir KASLR, la protección que aleatoriza las direcciones de memoria del kernel. Según el medio, el proceso tardó unos 53 minutos. La demostración se hizo contra un servidor que aceptaba conexiones Multipath TCP (MPTCP); no se ha demostrado públicamente la ejecución remota de código en sistemas sin un listener MPTCP.
Una carrera en el manejo de conexiones TCP
El fallo es un use-after-free: el kernel puede liberar opciones asociadas a un socket mientras otra operación todavía las está leyendo. La condición aparece durante el procesamiento concurrente de solicitudes TCP retransmitidas o durante la migración de sockets. Un atacante remoto puede enviar solicitudes de red con tiempos cuidadosamente elegidos para provocar esa carrera.
La vulnerabilidad se remonta a los kernels Linux desde 4.4 y afecta al subsistema IPv4 TCP. Aunque la demostración de Anthropic usó MPTCP, el problema también alcanza conexiones TCP ordinarias. Red Hat señala que el fallo puede causar corrupción de memoria o un bloqueo del sistema; su portal indica que explotar la carrera requiere precisión, pero no privilegios ni interacción del usuario.
MPTCP permite que una conexión use varias rutas de red al mismo tiempo, por ejemplo, conexiones Wi-Fi y móviles. No suele estar habilitado por defecto en las aplicaciones, pero BleepingComputer advierte que Go 1.24 activa MPTCP para listeners TCP en Linux cuando el kernel admite la función. Por eso algunos servicios escritos en Go podrían exponer un listener MPTCP sin que sus administradores lo hayan configurado expresamente.
Las evaluaciones de gravedad publicadas no son idénticas. BleepingComputer describió una valoración de Red Hat de 5,9, centrada en un posible ataque de denegación de servicio y en la complejidad de explotar la carrera. En cambio, la página de Red Hat para la CVE la califica como crítica y muestra una puntuación CVSS preliminar de 9,8; el boletín de seguridad de la compañía también la clasifica como crítica.
Los parches llegan por distribución
El defecto ya se corrigió en el kernel principal de Linux y el arreglo se trasladó a ramas mantenidas, pero las actualizaciones no están disponibles todavía para todas las distribuciones. Canonical indicó que Ubuntu 22.04 LTS, 24.04 LTS, 26.04 LTS y 26.10 seguían afectadas, con correcciones en preparación. Red Hat incluye RHEL 8, 9 y 10 entre los productos afectados; RHEL 7 no está afectado porque su kernel no contiene el código vulnerable.
Debian publicó versiones corregidas del paquete del kernel para Debian 12 y 13: 6.1.190-1 y 6.12.113-1, respectivamente. Amazon Web Services también anunció que ya están disponibles paquetes de kernel corregidos para Amazon Linux 2 y Amazon Linux 2023. En instancias Linux autogestionadas de EC2, la actualización del kernel y el reinicio corresponden al cliente.
Para los sistemas que aún esperan el parche, Red Hat y CIQ recomiendan filtrar el tráfico IPv4 TCP que contiene opciones IP como medida temporal. Red Hat advierte que ese filtrado puede afectar cargas de trabajo y no sustituye la actualización. AWS propone desactivar MPTCP o, en aplicaciones construidas con Go 1.24 o posterior, establecer GODEBUG=multipathtcp=0; la compañía aclara que estas medidas reducen las condiciones para ejecutar código, pero no resuelven la vulnerabilidad.
Desactivar MPTCP por sí solo tampoco basta para cerrar el riesgo: el fallo puede activarse mediante tráfico TCP ordinario. A fecha del aviso de BleepingComputer, no había informes confirmados de explotación de CVE-2026-98432 en ataques reales. La recomendación para los administradores es revisar el aviso de seguridad de su distribución e instalar el kernel corregido en cuanto esté disponible.
Fuentes: BleepingComputer, Red Hat Customer Portal, Red Hat, Amazon Web Services, Inc.
