Seguir Una vulnerabilidad crítica en la pila de red TCP IPv4 del núcleo de Linux podría permitir a un atacante remoto no autenticado provocar una corrupción de memoria, bloquear sistemas vulnerables y potencialmente ejecutar código arbitrario con privilegios de root. Rastreadada como CVE-2026-98432, la falla tiene un puntaje CVSS 3.1 de 9.8 y ha existido en el núcleo de Linux desde la versión 4.4.
La vulnerabilidad se origina a partir de una condición de carrera que puede hacer que el núcleo acceda a datos de opciones IP después de que la memoria subyacente ya ha sido liberada. Un atacante capaz de alcanzar un servicio TCP IPv4 expuesto puede intentar activar la condición utilizando solicitudes de conexión especialmente cronometradas que contienen opciones IPv4. No se requiere autenticación, privilegios locales o interacción del usuario.
El interés por la seguridad aumentó significativamente después de que Anthropic divulgara que un modelo de investigación interna Claude había desarrollado un exploit funcional capaz de lograr la ejecución remota de comandos root contra un servidor Linux con un listener Multipath TCP (MPTCP). El exploit primero filtra un puntero de núcleo para eludir KASLR y luego utiliza la misma condición de uso después de liberar para corromper la memoria y redirigir el flujo de control del núcleo. Anthropic no ha publicado el código del exploit.
Es importante destacar que la vulnerabilidad subyacente no se limita a MPTCP. Red Hat confirma que los sistemas con redes TCP IPv4 ordinarias siguen siendo vulnerables incluso cuando MPTCP está deshabilitado, incluidas las configuraciones predeterminadas de Red Hat Enterprise Linux.
A partir del 4 de noviembre de 2026, ningún proveedor de Linux, CERT u otra fuente revisada ha reportado explotación confirmada de la falla en ataques reales. Existen códigos de investigación pública que muestran parte de la vulnerabilidad, pero no se ha documentado un exploit publicado públicamente que proporcione la capacidad completa de root remoto demostrada por Anthropic.
Los equipos de seguridad pueden usar la Plataforma de Inteligencia de Detección Nativa de IA de SOC Prime para fortalecer sus defensas contra la explotación de vulnerabilidades emergentes, operacionalizar la inteligencia de amenazas y acelerar la búsqueda de amenazas en entornos SIEM, EDR, XDR y Data Lake.
Detectar CVE-2026-98432 mediante el monitoreo de tráfico TCP IPv4 inusual que contenga opciones IP, intentos de conexión repetidos diseñados para activar condiciones de carrera, interrupciones o eventos de corrupción de memoria del núcleo y actividad sospechosa que podría indicar una post-explotación exitosa.
El contenido de detección puede no estar disponible para cada CVE. Verifique la Plataforma SOC Prime para la cobertura actual. Si aún no están disponibles las detecciones relevantes, revise de nuevo ya que continuamente se agregan nuevas inteligencias de amenazas y contenido de detección.
Análisis de CVE-2026-98432
CVE-2026-98432 afecta el código de manejo de conexiones TCP IPv4 en núcleos de Linux que contienen la implementación vulnerable introducida en Linux 4.4. El equipo de CVE del núcleo de Linux clasifica el tema como crítico con un puntaje CVSS 3.1 de 9.8 y el vector AV/AC/PR/UI/S/C/I/A.
La vulnerabilidad es una condición de uso después de liberar causada por una carrera durante el procesamiento concurrente de conexiones TCP. Cuando se establece una conexión TCP IPv4, tcp_v4_syn_recv_sock() transfiere las opciones IP asociadas con la solicitud pendiente al socket recién creado sin hacer una copia separada.
Otro CPU puede procesar simultáneamente un SYN retransmitido asociado con el mismo socket de solicitud. Durante ese proceso, las funciones responsables de generar el SYN-ACK continúan leyendo las opciones IP mientras están protegidas por una sección crítica de lectura RCU.
Sin embargo, el socket hijo puede ser destruido mientras esa operación aún está en curso. Luego, el núcleo libera la estructura inet_opt asociada usando kfree(), dejando que otro CPU potencialmente acceda a la memoria que ya ha sido liberada. La referencia obsoleta resultante crea una condición de uso después de liberar en ip_options_build().
Una carrera similar existe durante la migración del socket de solicitud, incluidas las configuraciones que usan net.ipv4.tcp_migrate_req=1 o SK_REUSEPORT_SELECT_OR_MIGRATE basado en BPF. La solución ascendente reemplaza la liberación de memoria insegura con la liberación consciente de RCU, asegurando que los lectores hayan terminado de acceder al objeto antes de que su memoria pueda ser recuperada.
El primer problema afecta específicamente a IPv4. El aviso del núcleo establece que IPv6 no es vulnerable a esa carrera en particular porque tcp_v6_syn_recv_sock() duplica las opciones relevantes en lugar de transferirlas de la misma manera.
La explotación remota requiere tráfico de red especialmente construido y manipulación precisa de la condición de carrera. Red Hat señala que los resultados probables pueden incluir un bloqueo del núcleo, corrupción de memoria y potencialmente ejecución remota de código. La falta de autenticación e interacción del usuario aumenta sustancialmente el riesgo para los sistemas que exponen servicios TCP a redes no confiables.
Anthropic demostró que la vulnerabilidad puede transformarse en un exploit completo de root remoto. Su modelo de investigación apuntó a un servidor Linux que aceptaba conexiones TCP Múltiples y utilizó dos etapas para lograr la ejecución de comandos.
Durante la primera etapa, el exploit activa repetidamente la carrera y manipula un valor de longitud para que el núcleo devuelva memoria adyacente adicional en una respuesta de red. Eventualmente, una de estas respuestas contiene un puntero de núcleo. Esa divulgación revela información sobre el diseño de memoria del núcleo y permite que el exploit derrote la aleatorización del diseño del espacio de direcciones del núcleo (KASLR).
Durante la segunda etapa, el exploit utiliza la misma vulnerabilidad para causar un desbordamiento de búfer y sobrescribir un puntero de callback. El puntero se redirige hacia una carga útil previamente colocada en la memoria del núcleo utilizando funcionalidad de protocolo legítima. Cuando el núcleo invoca el callback modificado, las funciones existentes del núcleo se encadenan hasta que se ejecuta un comando de shell seleccionado por el atacante como root.
Una característica particularmente importante del exploit es que perder la carrera no necesariamente bloquea el servidor. En su lugar, el intento de conexión puede simplemente fallar, permitiendo que el atacante intente nuevamente repetidamente. En el entorno de prueba de Anthropic, obtener un puntero de núcleo útil tomó aproximadamente 48 minutos, seguido de otros cinco minutos para lograr la ejecución de comandos de root.
Esta demostración no debe interpretarse como que el MPTCP sea requerido para la explotación. Anthropic demostró una ruta de exploit exitosa que involucra un listener MPTCP, pero el código vulnerable reside en el manejo ordinario de TCP IPv4. Red Hat advierte explícitamente que deshabilitar MPTCP no aborda totalmente la vulnerabilidad y que las instalaciones predeterminadas de RHEL siguen afectadas incluso aunque MPTCP esté desactivado por defecto.
La situación del PoC de CVE-2026-98432 también es importante de diferenciar de la existencia de un exploit completamente armado. Anthropic desarrolló un concepto de prueba de root remoto funcional internamente pero no lo ha publicado. El código público reportado por investigadores de seguridad puede demostrar o detectar aspectos de la carrera subyacente y divulgación de memoria, pero las fuentes revisadas no documentan un código publicado públicamente que reproduzca la cadena completa de ejecución de código remoto de Anthropic.
La vulnerabilidad fue reportada por el investigador de Anthropic Xinyang Ge. La solución ascendente de Linux fue aplicada el 5 de octubre de 2026, mientras que el registro de CVE del núcleo de Linux fue publicado el 15 de octubre. Anthropic describió públicamente su investigación completa de explotación el 27 de octubre.
El proyecto del núcleo de Linux identifica las siguientes versiones corregidas:
- Linux 5.10.272
- Linux 5.15.223
- Linux 6.1.190
- Linux 6.6.159
- Linux 6.12.113
- Linux 6.18.56
- Linux 7.2.10
- Linux 7.3
El equipo del núcleo recomienda actualizar al último núcleo estable en lugar de realizar cherry-picking de commits individuales.
La exposición específica de la distribución y la remediación difieren porque los proveedores de Linux mantienen sus propios núcleos y retroalimentan correcciones de seguridad. Red Hat actualmente clasifica el problema como crítico en 9.8 y ha lanzado correcciones para múltiples flujos de RHEL 8, 9 y 10. OpenShift y productos en capas que dependen de núcleos RHEL afectados también requieren atención.
Ubuntu también clasifica la vulnerabilidad como crítica en 9.8. Ubuntu 26.10 ha recibido un núcleo genérico corregido, mientras que las correcciones para Ubuntu 22.04 LTS, 24.04 LTS y 26.04 LTS estaban disponibles en el bolsillo de pruebas -proposed a principios de noviembre, con lanzamientos adicionales soportados a la espera de correcciones. Los administradores deben usar la página CVE de Canonical en lugar de confiar únicamente en los números de versión del núcleo ascendente.
Para la detección de CVE-2026-98432, los equipos de seguridad deben combinar telemetría de red y de host. Las señales de búsqueda potencial a nivel de red incluyen paquetes TCP IPv4 entrantes inusuales que transportan opciones IP, especialmente intentos de conexión repetidos que contienen opciones de Record Route o Timestamp y patrones anormales de retransmisión SYN. La presencia de tal tráfico por sí sola no confirma explotación, pero proporciona un pivote útil para la búsqueda cuando se correlaciona con sistemas vulnerables.
El monitoreo a nivel de host debe incluir fallos del núcleo de Linux, advertencias del núcleo, indicadores de corrupción de memoria, reinicios inesperados de servicios y actividad anómala inmediatamente después del tráfico de red sospechoso. Debido a que la explotación exitosa podría teóricamente proporcionar ejecución de código root, los defensores también deben monitorear procesos privilegiados inesperados, archivos recién creados, cambios de configuración, mecanismos de persistencia y conexiones salientes inexplicadas.
Actualmente no hay IOCs de CVE-2026-98432 específicos de atacantes, como direcciones IP, dominios o hashes de malware confirmados como maliciosos, ya que las fuentes revisadas no han informado explotación en el mundo real. Por lo tanto, los defensores deben priorizar la detección basada en comportamiento y evaluación de exposición en lugar de depender de indicadores estáticos.
Mitigación de CVE-2026-98432
La remediación definitiva es instalar un núcleo proporcionado por el vendedor que contenga la corrección de seguridad. El equipo de CVE del núcleo de Linux recomienda moverse al último núcleo estable soportado, mientras que los usuarios de distribuciones de Linux deben instalar paquetes suministrados específicamente por su proveedor porque las correcciones comunmente se retroalimentan sin cambiar a una versión de núcleo ascendente.
Los administradores deben priorizar servidores Linux expuestos a Internet y otros sistemas que aceptan conexiones TCP IPv4 entrantes. La superficie de ataque es amplia porque la vulnerabilidad existe en la pila de red del núcleo en lugar de en una aplicación individual o producto de servidor.
Las organizaciones deben tomar los siguientes pasos:
- Inventariar servidores Linux e identificar el núcleo en ejecución con herramientas como uname -r.
- Consultar el aviso de seguridad de la distribución de Linux relevante en lugar de determinar la exposición únicamente a partir del número de versión ascendente.
- Instalar el núcleo corregido proporcionado por el vendedor tan pronto como esté disponible.
- Reiniciar los sistemas afectados después de instalar el núcleo actualizado para asegurar que el núcleo parcheado esté en ejecución.
- Priorizar servidores e infraestructuras expuestas a Internet que aceptan tráfico TCP IPv4 entrante.
- Revisar servicios TCP expuestos externamente y limitar el acceso a la red innecesario.
- Seguir monitoreando avisos de proveedores porque la disponibilidad de soluciones difiere entre distribuciones de Linux, variantes de núcleo, núcleos en la nube y canales de soporte.
Red Hat y Ubuntu también han documentado un enfoque interino de filtrado de paquetes que descarta paquetes TCP IPv4 entrantes que contienen opciones IP. La condición recomendada por nftables verifica una longitud de encabezado IPv4 mayor que cinco y descarta paquetes TCP coincidentes antes de que alcancen la ruta de manejo del socket vulnerable.
Esta medida puede reducir la exposición porque la trayectoria de explotación conocida requiere opciones IPv4. Sin embargo, ambos proveedores advierten que el filtrado de paquetes no es un reemplazo completo para instalar el núcleo corregido. También puede interferir con cargas de trabajo que dependen legítimamente de las opciones IPv4, por lo que debe probarse antes del despliegue en producción.
Deshabilitar MPTCP por sí solo no debe tratarse como una protección suficiente. Aunque el exploit funcional de Anthropic apuntó a un listener MPTCP, la vulnerabilidad subyacente está en el manejo normal de TCP IPv4. Red Hat específicamente nota que RHEL sigue siendo vulnerable en su configuración predeterminada incluso cuando MPTCP está desactivado.
Para entornos que usan aplicaciones Go, deshabilitar el comportamiento automático de MPTCP puede reducir la exposición al exploit específico demostrado por Anthropic, pero esto sigue siendo una medida de reducción de riesgo incompleta. Los sistemas sin un listener MPTCP no deben considerarse automáticamente seguros porque otras técnicas de explotación pueden apuntar a la misma carrera subyacente.
Debido a que no se ha confirmado ninguna campaña de compromiso en el mundo real, la orientación de respuesta a incidentes actualmente debe centrarse en identificar sistemas potencialmente vulnerables y comportamientos de explotación sospechosos en lugar de buscar un conjunto de infraestructura de atacante conocido. Las organizaciones que observen tráfico TCP inusual seguido de inestabilidad del núcleo o ejecución privilegiada inesperada deben tratar la actividad como potencialmente maliciosa y preservar la telemetría de red y host para su investigación.
FAQ
¿Qué es CVE-2026-98432 y cómo funciona?
CVE-2026-98432 es una vulnerabilidad crítica de uso después de liberar en el subsistema de red TCP IPv4 del núcleo de Linux. Durante el procesamiento concurrente de solicitudes de conexión TCP, la memoria de opción IP puede ser liberada mientras otro CPU todavía la esté accediendo. Solicitudes de red remotas especialmente cronometradas pueden activar la carrera, potencialmente causando bloqueos, corrupción de memoria, divulgación de información o ejecución remota de código.
¿Cuándo se descubrió por primera vez CVE-2026-98432?
La vulnerabilidad fue reportada por el investigador de Anthropic Xinyang Ge. La solución ascendente de Linux se implementó el 5 de octubre de 2026 y el registro de CVE del núcleo de Linux fue publicado el 15 de octubre. Anthropic divulgó públicamente su técnica de explotación remota y root funcional el 27 de octubre de 2026.
¿Cuál es el impacto de CVE-2026-98432 en los sistemas?
Un atacante remoto no autenticado puede activar una condición de uso después de liberar en el núcleo de Linux a través del tráfico TCP IPv4. Las posibles consecuencias incluyen denegación de servicio a través de un bloqueo del núcleo, divulgación o corrupción de memoria del núcleo, y potencialmente ejecución arbitraria de comandos con privilegios de root. Anthropic demostró una ejecución remota exitosa de root contra un sistema con un listener MPTCP.
¿CVE-2026-98432 todavía puede afectarme en 2026?
Sí. Los sistemas que ejecutan núcleos de Linux vulnerables permanecen expuestos hasta que se instale la actualización de seguridad del proveedor apropiada y el núcleo parcheado esté en ejecución. El error subyacente ha existido desde Linux 4.4, y las distribuciones afectadas incluyen plataformas Linux empresariales principales. Sin embargo, a partir del 4 de noviembre de 2026, las fuentes revisadas no reportan explotación confirmada de la vulnerabilidad en ataques reales.
¿Cómo puedo protegerme de CVE-2026-98432?
Instale el último núcleo corregido proporcionado por su distribución de Linux y reinicie el sistema para activarlo. Priorice los servidores que aceptan conexiones TCP IPv4 entrantes y verifique la exposición utilizando el aviso del proveedor. Donde el parcheo inmediato no sea posible, filtrar los paquetes TCP IPv4 entrantes que contengan opciones IP puede reducir el riesgo, pero no es un sustituto completo para la actualización. Los equipos de seguridad deben seguir revisando los avisos de los proveedores para detalles actualizados sobre CVE-2026-98432 a medida que estén disponibles correcciones y investigaciones adicionales.
