Introducción
La superficie de ataque del kernel Linux acaba de ampliarse significativamente para los entornos cloud modernos. Un equipo de investigación de Anthropic logró ejecutar comandos arbitrarios con privilegios de root en un servidor Linux remoto, sin necesidad de credenciales ni interacción del usuario. El vector principal es el protocolo Multipath TCP (MPTCP), una característica que permite a una sola conexión utilizar múltiples rutas de red simultáneamente para mejorar la resiliencia y el ancho de banda. Aunque MPTCP se asocia comúnmente con dispositivos móviles que alternan entre Wi-Fi y datos celulares, su implementación en servidores es cada vez más frecuente debido a cambios recientes en entornos de desarrollo y frameworks de nube.
El problema no radica únicamente en el protocolo, sino en cómo el kernel gestiona la memoria durante el establecimiento de conexiones bajo condiciones específicas de concurrencia. Lo que inicialmente se clasificó como un riesgo potencial de denegación de servicio (DoS) por parte de proveedores empresariales como Red Hat, resultó ser una vulnerabilidad de ejecución remota de código (RCE) en escenarios controlados. Esta discrepancia en la severidad percibida subraya la importancia de validar los exploits reales frente a las teorías de mitigación estáticas, especialmente cuando el impacto puede escalar de un simple crash del kernel a la toma total de control del sistema.
Qué ocurrió
La vulnerabilidad, identificada como CVE-2026-98432, es una falla de tipo «use-after-free» en el código de red IPv4 TCP del kernel Linux. El equipo de Anthropic desarrolló un exploit utilizando un modelo de IA no publicado que logró evadir la aleatorización de la dirección del espacio de kernel (KASLR). En pruebas controladas sobre un servidor con listener MPTCP habilitado, el ataque tardó aproximadamente 53 minutos en conseguir la ejecución remota de código como root. Este tiempo es crítico para los equipos de seguridad, ya que sugiere una ventana de oportunidad viable para ataques automatizados o persistentes, no solo para pruebas de concepto puntuales.
Es fundamental distinguir entre el riesgo teórico y el demostrable. El equipo de seguridad del kernel Linux asignó una puntuación CVSS de 9.8 debido a la gravedad potencial de la ejecución de código. Sin embargo, Red Hat mantuvo una calificación más conservadora de 5.9, argumentando que la complejidad para explotar la condición de carrera mediante el envío simple de paquetes maliciosos era alta y que el resultado más probable sería un crash del kernel (DoS) en lugar de RCE garantizado. La demostración de Anthropic refuta parcialmente esta postura al demostrar que, bajo condiciones específicas de carga y configuración, la RCE es alcanzable sin autenticación previa.
Además, la vulnerabilidad no se limita estrictamente a MPTCP. El subyacente error lógico afecta al manejo estándar de sockets TCP IPv4. Aunque no se ha demostrado públicamente la ejecución remota de código en servidores sin listener MPTCP, el riesgo de denegación de servicio y corrupción de memoria persiste en todo tráfico TCP que invoque las rutas de código afectadas. Esto amplía el alcance del problema a infraestructuras que ni siquiera utilizan funciones avanzadas de multipath, pero comparten el mismo núcleo vulnerable.
Impacto para DevOps / Infraestructura / Cloud / Seguridad
Para los equipos de infraestructura y cloud, la mayor sorpresa reside en la adopción automática de MPTCP por parte de lenguajes de programación modernos. A partir de Go 1.24, el compilador habilita listeners MPTCP por defecto en Linux siempre que el kernel soporte la característica. Esto significa que microservicios escritos en Go, desplegados en contenedores o máquinas virtuales con kernels vulnerables, podrían estar exponiendo esta superficie de ataque sin que los administradores lo hayan configurado explícitamente. La «mágica» habilitación automática crea una brecha entre la intención del desarrollador y la exposición real de red.
En entornos cloud como AWS, Azure o GCP, donde las instancias a menudo aceptan tráfico desde Internet o VPCs amplias, un listener vulnerable expuesto al público representa un riesgo inmediato. La combinación de Go 1.24 en contenedores Docker o Kubernetes con kernels Linux antiguos (desde la versión 4.4) crea una convergencia perfecta para el ataque. Los equipos de seguridad deben audicar no solo los puertos abiertos, sino también las versiones del kernel subyacente y las bibliotecas estándar utilizadas por los servicios expuestos.
La complejidad del exploit también impacta en la estrategia de detección de intrusiones. Dado que la condición de carrera requiere tiempos específicos de retransmisión SYN y procesamiento concurrente, los ataques pueden generar patrones de tráfico anómalos pero no necesariamente masivos como un flood tradicional. Los firewalls de capa 4 (L4) o las reglas WAF estándar podrían pasar por alto estos paquetes si no se inspeccionan opciones IP específicas dentro de la cabecera TCP.
Detalles técnicos
La vulnerabilidad surge de una condición de carrera en cómo el kernel transfiere la propiedad de estructuras de memoria entre sockets padre e hijo. Según el aviso del kernel, la función tcp_v4_syn_recv_sock() transfiere la propiedad de ireq->ireq_opt al socket hijo (newinet->inet_opt) sin realizar una copia profunda. Mientras tanto, otra CPU puede procesar concurrentemente un SYN retransmitido para el mismo socket de solicitud y enviar un SYNACK desde tcp_check_req().
El problema ocurre porque funciones como tcp_v4_send_synack() e inet_csk_route_req() leen ireq->ireq_opt utilizando únicamente rcu_read_lock(). Luego, ip_build_and_send_pkt() e ip_options_build() intentan leer opt->optlen dos veces. Si la memoria es liberada o modificada por el otro hilo entre estas lecturas, se produce una situación de use-after-free que puede corromper la memoria del kernel y eventualmente derivar en ejecución de código arbitrario si el atacante logra controlar los bytes residuales en esa dirección de memoria.
Un escenario adicional ocurre durante la migración de sockets de solicitud TCP cuando está habilitada la sysctl net.ipv4.tcp_migrate_req, o cuando se utiliza un programa BPF con BPF_SK_REUSEPORT_SELECT_OR_MIGRATE. Esto indica que las configuraciones avanzadas de balanceo de carga a nivel de kernel en entornos de alta concurrencia (típicos en proxies inversos o gateways API) también están expuestas.
Las versiones afectadas incluyen el kernel Linux desde la 4.4 en adelante. Distribuciones específicas como Ubuntu, Red Hat Enterprise Linux (RHEL) y Rocky Linux se ven impactadas. Por el contrario, RHEL 7 no es vulnerable porque su kernel base no contiene el código específico introducido que introduce esta regresión lógica en el manejo de opciones IP durante la creación del socket hijo.
Qué deberían hacer los administradores y equipos técnicos
La prioridad inmediata es identificar si sus servidores están ejecutando kernels vulnerables y si tienen listeners MPTCP activos, especialmente si utilizan Go 1.24+. Dado que los parches oficiales aún no han llegado a todas las distribuciones LTS principales, la mitigación activa es crucial para sistemas expuestos a Internet.
Para Ubuntu 22.04, 24.04 y versiones posteriores donde el parche del kernel aún está en proceso (según Canonical), se recomienda restringir el acceso a los puertos afectados mediante firewalls de nivel de sistema o cloud security groups. Si utiliza nftables, puede aplicar reglas temporales para bloquear paquetes TCP IPv4 que contengan opciones IP específicas, reduciendo la probabilidad de disparar la condición de carrera antes del parche definitivo.
Comando sugerido para verificar si MPTCP está habilitado y activo en el kernel:
sysctl net.mptcp.enabledPara mitigar el riesgo sin desactivar MPTCP completamente (lo cual podría afectar rendimiento), CIQ sugiere bloquear paquetes con opciones IP antes de que lleguen al código TCP vulnerable. Un ejemplo conceptual de regla nftables para filtrar tráfico sospechoso en interfaces externas puede incluir la inspección de cabeceras, aunque debe validarse en un entorno de staging para no interrumpir servicios legítimos que dependan de estas opciones.
Si gestiona flotas de contenedores con Go 1.24+, considere temporalmente retroceder a una imagen base del sistema operativo con un kernel parcheado o deshabilitar explícitamente MPTCP en la configuración del servicio si no es estrictamente necesario para su arquitectura de red actual.
Conclusión
La CVE-2026-98432 destaca cómo las optimizaciones de rendimiento y conveniencia, como el habilitado automático de MPTCP en Go 1.24, pueden introducir superficies de ataque inadvertidas en infraestructuras críticas. La demostración de Anthropic eleva la prioridad de este bug de un riesgo operativo interno a una amenaza externa viable para servidores expuestos.
Mientras los proveedores de Linux finalizan y distribuyen los parches del kernel, la dependencia de mitigaciones de red y firewalls es inevitable. Los equipos DevOps deben monitorear activamente los trackers de seguridad de sus distribuciones (Ubuntu, RHEL, Debian) para aplicar las actualizaciones en cuanto estén disponibles, priorizando aquellos servidores que corran servicios Go 1.24+ o con kernels de la serie 4.4-5.x sin soporte extendido reciente.
Fuentes
https://www.bleepingcomputer.com/news/security/critical-linux-kernel-flaw-allows-remote-root-attacks-on-mptcp-servers/