Gestiono servidores Debian en producción desde hace años. Cada vez que sale una CVE sobre el kernel, me detengo a leer los detalles. Después decido si actualizar enseguida o esperar. Esta vez la historia es más enredada de lo habitual: hay una vulnerabilidad del kernel Linux en el TCP IPv4, una puntuación CVSS discutida entre proveedores, e incluso un supuesto exploit root construido por una inteligencia artificial. Empecemos por una pregunta que parece lateral, pero no lo es: qué es MPTCP, y por qué importa aunque no lo uses.
Qué es MPTCP y por qué afecta también a quien no lo usa
Multipath TCP (MPTCP) es el estándar RFC 8684. Extiende el TCP clásico para que una sola conexión viaje por varias rutas de red a la vez. Un teléfono puede usar WiFi y red móvil en el mismo momento, para la misma conexión. Un servidor con varias interfaces puede hacer lo mismo, por redundancia o por suma de ancho de banda. Apple lo usa en producción desde iOS 7, en 2013, para Siri: es el caso de uso real más conocido. Algunos operadores móviles, por ejemplo en Corea del Sur, lo aprovechan para el bonding WiFi/LTE. Varios centros de datos lo adoptan para el multi-homing entre distintos uplinks. En el kernel Linux mainline está desde la versión 5.6.
El punto que me hizo levantar una ceja es otro. Desde la versión 1.24, los programas escritos en Go requieren MPTCP por defecto para los sockets en escucha. El Go Security Team lo confirmó el 29 de octubre. Junto con eso, dio un aviso incómodo: el bug del que hablamos hoy no es específico de MPTCP. Un sistema sin listeners MPTCP activos puede seguir expuesto a ataques similares. El código vulnerable está en el path TCP IPv4 genérico, no en un módulo opcional. Se puede desactivar MPTCP programa por programa, con la variable GODEBUG=multipathtcp=0 en tiempo de ejecución. Pero el Go Security Team define esta mitigación como «frágil»: basta un solo listener MPTCP expuesto para anularla. Nadie ha demostrado que todo exploit funcional dependa realmente de MPTCP. Por eso el código de MPTCP sigue siendo superficie de ataque, aunque en tu stack no lo actives nunca de forma consciente: basta con que esté compilado en el kernel y sea alcanzable.
El propio proyecto MPTCP declara, en su página, que las principales distribuciones Linux actuales envían el kernel con el soporte MPTCP compilado por defecto (CONFIG_MPTCP=y). Menciona explícitamente a Debian, Ubuntu, RHEL y Fedora. Es una declaración del propio proyecto, no una verificación independiente distro por distro, pero el concepto sigue siendo válido: el soporte está activado a nivel de kernel, no es «opt-in» a nivel de sistema operativo. Solo la negociación por conexión individual queda a cargo de la aplicación.
La vulnerabilidad del kernel Linux CVE-2026-98432 en resumen
El CVE team del kernel Linux publicó la CVE-2026-98432 el 15 de octubre de 2026. El fix upstream ya se había aplicado diez días antes, el 5 de octubre. Suele pasar que la publicación sigue al commit con cierto retraso. La puntuación CVSS de 9,8 (crítico) llegó solo el 24 de octubre, nueve días después de la publicación de la CVE.
El problema está en la gestión del handshake TCP para IPv4, en concreto en la función tcp_v4_syn_recv_sock(). Cuando se crea una conexión, las opciones IP del paquete SYN se pasan del request socket en espera al nuevo socket. Por ejemplo Record Route o Timestamp, si el cliente las incluye en un SYN construido a propósito. El problema es que se pasan por referencia, no por copia, y sin el lock del listener. Según el análisis técnico del parche, las estructuras implicadas se llaman inet_opt e ireq_opt. Una segunda CPU puede liberar ese buffer con kfree(), llamado desde inet_sock_destruct() o desde tcp_v4_reqsk_destructor(). Mientras tanto una primera CPU todavía lo está leyendo en ip_options_build(), para construir el SYNACK. Es un clásico use-after-free causado por una race condition. El path IPv6 equivalente, tcp_v6_syn_recv_sock(), copia las opciones en lugar de pasarlas por referencia: no es vulnerable a la race principal. Existe también una segunda vía de ataque, mediante la migración de request-sockets: net.ipv4.tcp_migrate_req=1 o un programa eBPF BPF_SK_REUSEPORT_SELECT_OR_MIGRATE. Ambas están desactivadas por defecto.
El bug es remoto y no requiere autenticación ni interacción del usuario, según la evaluación del kernel team. Está presente desde la versión 4.4 del kernel. El fix lo firma Eric Dumazet, reportado por Xinyang Ge de Anthropic. Mueve la liberación de memoria a después de un grace period RCU, con kfree_rcu(): así ninguna CPU puede volver a leer un buffer ya liberado. Las versiones estables corregidas son 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 y la mainline desde la 7.3-rc7.
Puntuaciones CVSS discordantes: no todos los proveedores están de acuerdo
Aquí la historia se complica. El kernel CVE team y Ubuntu valoran la complejidad del ataque como baja, y dan 9,8 (crítico). Oracle y SUSE dan en cambio 8,1 (importante): mismo vector CVSS, pero complejidad de ataque alta. Red Hat, curiosamente, tiene dos valoraciones que no coinciden entre sí. La página pública de la CVE muestra «Moderate, 5.9». El archivo de advisory legible por máquina, actualizado el 29 de octubre, muestra en cambio «Important, 8.1», con impacto alto en confidencialidad e integridad. Ese mismo día el bug tracker interno de Red Hat subió la severidad de medium a high. Amazon, por su parte, asigna 7,0. En el momento de escribir esto, el NVD todavía no ha publicado una puntuación propia.
Vale la pena decirlo con honestidad. Esta incoherencia interna de Red Hat no es un detalle que haya deducido yo: así la reporta el artículo original de The Hacker News, mi fuente principal para estos datos. No es la primera vez que un proveedor publica dos números distintos para el mismo bug, en canales diferentes. Pero aquí el salto de «moderado» a «importante» el mismo día dice mucho. Incluso para quien escribe el código, estimar con certeza la explotabilidad real de una race condition en el kernel es difícil.
Estado de los parches: Debian ya corregido, otros todavía no
Este es el punto que me toca más de cerca: los hostings que gestiono corren sobre Debian stable. Y aquí los hechos hablan claro, sin necesidad de añadir énfasis: Debian ya ha corregido esta vulnerabilidad del kernel Linux, tanto en trixie como en bookworm. Debian trixie (stable) se corrigió el 16 de octubre de 2026, con el paquete linux 6.12.113-1, aviso DSA-6568-1. Debian 12 (bookworm) se corrigió en dos pasos: el 17 y el 22 de octubre de 2026, con linux 6.1.190-1 (aviso DLA-4841-1) y linux-6.12 6.12.113-1~deb12u1 (aviso DLA-4850-1). En su propia tabla de seguimiento, Debian no indica una puntuación CVSS separada para esta CVE. Se limita a marcar el estado del fix para cada release: es la información que realmente importa, para quien tiene que decidir si reinicia un servidor.
Comparar esto con el estado de otras distribuciones muy usadas ayuda a darle peso al asunto. Al 30 de octubre, Red Hat actualizó el estado de RHEL 8, 9, 10 y OpenShift 4. Antes era «fix deferred» (marcado el 29 de octubre), ahora es «affected». No se ha comunicado ninguna fecha de publicación. Ubuntu, en todas las versiones soportadas (22.04, 24.04, 26.04, 26.10), sigue «en curso», sin fecha. Ubuntu 16.04, 18.04 y 20.04 resultan vulnerables, sin ningún fix listado siquiera. SUSE Linux Enterprise Server, desde la SP4 hasta la SP7 más la 16.0, está en la misma situación. Oracle Linux (UEK), openSUSE Leap 16.0, SUSE Linux Micro 6.2 y Amazon Linux 2023 ya están corregidos. RHEL 7 no está afectado: el path de código vulnerable nunca se distribuyó en esa release.
No lo digo para hacerle competencia a Ubuntu o RHEL. Siguen siendo distribuciones serias, con procesos de seguridad robustos. Lo digo porque en este bug concreto, en esta ventana temporal, los hechos son estos: quien confía en hostings basados en Debian stable ya tiene el fix instalado. En otras distribuciones muy usadas, en cambio, el servidor queda expuesto por un periodo indefinido. Es una ventaja concreta, verificable mirando las fechas. No es una opinión sobre el proyecto Debian en general.
El exploit (reportado, no verificado de forma independiente) de Anthropic
La parte más insólita de esta historia tiene que ver con Anthropic, la empresa que primero reportó el bug a través de Xinyang Ge. Según los informes del sector, uno de sus modelos de IA internos, no publicado, construyó por su cuenta un exploit root funcional. Partiendo solo del parche y del informe como prompt. El ataque en dos fases funcionaría así. En la primera fase, la race hace que el atacante reciba bytes extra de la respuesta del kernel. De ahí recupera una dirección del kernel, para desactivar KASLR. En la segunda fase, el mismo bug causaría un overflow de buffer. Sobrescribe un puntero de callback con la dirección de un payload ya colocado en memoria del kernel por el atacante. Cuando el kernel llama a ese puntero, el payload ejecuta un comando de shell a elección como root. Una race perdida haría fallar solo ese intento de conexión, sin que el sistema se caiga: así que serían posibles intentos repetidos. En la prueba descrita por Anthropic: 48 minutos para robar la dirección del kernel, otros 5 minutos para llegar a la ejecución de comandos.
Red Hat dice que un atacante remoto que alcance un servicio TCP expuesto puede, en general, provocar la race. El exploit root descrito por Anthropic, sin embargo, habría apuntado específicamente a servidores con un listener multipath TCP activo. La publicación de Anthropic no aclara si un servidor sin MPTCP es explotable del mismo modo. Ni el registro CVE ni el fix upstream mencionan MPTCP en ningún punto. Es la prensa del sector, no una fuente primaria, la que reporta este vínculo: por eso lo escribo con el escepticismo que merece, no como un hecho confirmado al cien por cien. Anthropic no ha publicado el código del exploit, ni la versión exacta del kernel usada, ni la configuración del servidor objetivo. Otra empresa, Innora, publicó un análisis de la causa raíz, con un entorno de reproducción en QEMU. Declaró que no publicará un exploit armado a corto plazo. Por ahora no hay pruebas de explotación real por parte de proveedores o CERT. El bug no está en el catálogo CISA KEV, según la copia actualizada por CIRCL de Luxemburgo al 28 de octubre.
Qué hacer ahora en tus servidores
Ningún proveedor ha publicado un workaround oficialmente sancionado para esta vulnerabilidad del kernel Linux. Red Hat dice explícitamente que ninguna de las medidas circuladas hasta ahora alcanza su estándar de facilidad de despliegue y estabilidad. La mitigación primaria sigue siendo aplicar el kernel corregido y reiniciar, cuando el parche esté disponible para tu distribución. En Debian ya lo está. En RHEL y Ubuntu, todavía no, en el momento en que escribo esto.
Como defensa en profundidad, no como solución definitiva, tiene sentido hacer algunas cosas. Comprobar que net.ipv4.tcp_migrate_req esté puesto a 0. Verificar que no haya programas eBPF BPF_SK_REUSEPORT_SELECT_OR_MIGRATE cargados. Evaluar un filtrado de los paquetes IPv4 entrantes con opciones Record Route o Timestamp. Monitorizar posibles crashes que mencionen ip_options_build, ip_build_and_send_pkt o skb_under_panic. Hacer inventario de los listeners MPTCP expuestos, evitando dejarlos alcanzables sin motivo. Si también gestionas servicios frente a ataques de aplicación más comunes, en cómo protegí los servidores a la espera del parche para PHP2Shell encontrarás el mismo enfoque: mitigar lo que se puede, mientras se espera el fix definitivo, sin prometer protecciones que no existen.
Para quien me pregunta si actualizar ya: si usas Debian stable, el kernel corregido ya está en los repositorios de seguridad. La actualización es sencilla, y la ventana de exposición ya está cerrada. Si usas otras distribuciones, hoy todavía no hay un parche que instalar. Vale la pena seguir de cerca los avisos de tu proveedor en los próximos días: la situación cambia rápido.
Fuentes: The Hacker News, Debian Security Tracker y el commit del fix. Debian, Red Hat, Ubuntu y los demás nombres citados son marcas de sus respectivos propietarios.
Deja una respuesta