Red Hat elevó el 2 de noviembre la puntuación CVSS de la vulnerabilidad del kernel de Linux CVE-2026-98432 a 9,8; antes le había dado notas de entre 5,9 y 8,1. La compañía publicó el 1 de noviembre kernels corregidos para RHEL 8, 9 y 10. En Ubuntu, el estado sigue siendo corrección en curso.
El fallo está en el proceso de establecimiento de conexiones TCP sobre IPv4 y puede activarse desde la red, sin autenticación y sin intervención del usuario. El alcance se cuenta desde Linux 4.4, y la raíz del problema se remonta a un commit de 2015.
Una condición de carrera que se corrige con dos líneas de código
Cuando un paquete SYN trae opciones IPv4 (como Record Route o Timestamp), el kernel las guarda en el socket de solicitud. Al completarse el handshake, el puntero a esa memoria se entrega directamente al socket hijo, sin copiarla, de modo que ambos comparten la misma zona.
Si en ese momento otra CPU está construyendo un SYN-ACK por un SYN retransmitido y el socket hijo se destruye justo entonces, la memoria de las opciones se libera de inmediato con kfree(). La ruta que construye el SYN-ACK acaba leyendo memoria ya liberada.
La corrección la envió Eric Dumazet, con el commit e3f33b0a1d89, y sustituye kfree() por kfree_rcu(), de modo que la liberación espera a que pase el periodo de gracia de RCU; solo toca dos líneas. Quien reportó la vulnerabilidad es Xinyang Ge, de Anthropic. El registro CVE se publicó el 15 de octubre; las versiones corregidas en las ramas estables son 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56 y 7.2.10, y en la rama principal la 7.3.
Lo que dice Anthropic solo puede demostrarlo ella misma
Lo que ha llamado la atención sobre este fallo es un artículo del Anthropic Frontier Red Team del 27 de octubre. Según el texto, un modelo interno aún no lanzado le escribió un programa de explotación que permite a un atacante remoto no autenticado ejecutar comandos como root en servidores con escucha MPTCP activada.
La explotación se divide en dos fases: primero se aprovecha la condición de carrera para leer memoria del kernel fuera de límites, filtrar punteros y esquivar KASLR; después, una escritura fuera de límites sobrescribe un puntero a función de callback. Anthropic da una duración de unos 48 minutos para filtrar el puntero y otros 5 minutos aproximadamente para lograr la ejecución de comandos.
Hay varios puntos que conviene separar. El código del exploit, las versiones de kernel de prueba y la configuración no se han publicado, y hasta ahora no hay verificación de terceros. Ni el registro CVE ni el commit de corrección mencionan MPTCP, y el artículo no explica por qué sería imprescindible. Los 53 minutos son una cifra obtenida en un entorno desconocido y no pueden trasladarse sin más a servidores en producción. A fecha de 2 de noviembre, ningún proveedor, CERT ni el equipo de CVE del kernel ha informado de explotación activa, y el catálogo de vulnerabilidades explotadas conocidas de la CISA tampoco la incluye.
En algunas publicaciones en chino se escribe que “Anthropic ha publicado ejemplos de explotación”. Con más precisión, lo que se publicó fue la descripción del proceso de explotación, no código ejecutable.
Tampoco se ha resuelto la discrepancia en la puntuación. El equipo de CVE del kernel y Red Hat dan ahora 9,8, mientras que Oracle, SUSE y Amazon dan 8,1; la diferencia está en si se valora la complejidad del ataque como baja o alta. El NVD aún no ha publicado su propia nota.
Go convirtió el requisito previo en valor por defecto
El aviso del equipo de seguridad de Go del 29 de octubre amplió el alcance. Desde Go 1.24, el valor por defecto de multipathtcp es 2, lo que significa activar MPTCP solo en el lado de escucha. Es decir, un programa en Go que levanta un servicio con net.Listen ya cumple por defecto el requisito previo que demostró Anthropic.
La mitigación que ofrece el equipo de Go es establecer GODEBUG=multipathtcp=0 en tiempo de ejecución, o escribir godebug multipathtcp=0 en el go.mod del módulo principal; al mismo tiempo, califica esta desactivación programa a programa de “a fragile mitigation” (una mitigación frágil). El equipo de Go considera prematuro cambiar ahora el valor por defecto. En el kernel se puede fijar net.mptcp.enabled en 0, lo que solo elimina el requisito demostrado; la vulnerabilidad en sí sigue ahí.
Qué pueden hacer primero los administradores
El estado de las distribuciones (parte comprobado el 29 de octubre y parte el 2 de noviembre) es, a grandes rasgos, el siguiente:
| Distribución | Estado |
|---|---|
| RHEL 8, 9, 10 | Corregido |
| RHEL 9 real-time, OpenShift 4 | Afectado, sin corrección por ahora |
| RHEL 7 | No afectado |
| Debian 12, 13 | Corregido |
| Ubuntu 22.04, 24.04, 26.04, 26.10 | Afectado, corrección en curso |
| Ubuntu 16.04, 18.04, 20.04 | Afectado, sin corrección por ahora |
| Amazon Linux 2, 2023 | Corregido |
| Oracle Linux (UEK) | Corregido |
Ubuntu tiene un peso nada desdeñable entre los usuarios de servidores en la nube, así que es la fila de esta tabla que más conviene vigilar. Las distribuciones corrigen sobre todo mediante backports, por lo que, para saber si un sistema está parcheado, hay que comparar las versiones de los paquetes con el aviso de seguridad de la propia distribución; fijarse solo en la versión principal de uname -r puede llevar a error. Tras instalar el kernel nuevo hay que reiniciar; el live patching es otro mecanismo y debe confirmarse por separado.
En las máquinas que por ahora no pueden recibir el parche, se puede empezar por inventariar qué servicios escuchan en MPTCP, sobre todo los binarios compilados con Go 1.24 o posterior, y después decidir si se desactivan con los métodos anteriores. Los proveedores no han confirmado que desactivar MPTCP elimine todo el riesgo, así que este paso solo sirve para ganar tiempo. Si en los registros de fallos del kernel aparecen funciones como ip_options_build, también conviene investigarlo.
Fuentes: relatos públicos del artículo del Anthropic Frontier Red Team, boletín de vulnerabilidades de Rescana, CocoLoop, aviso del equipo de seguridad de Go, páginas de seguimiento de seguridad de Debian y Red Hat; las puntuaciones y el estado de las correcciones se ciñen a lo que publica cada proveedor, y los detalles de explotación de Anthropic no se han verificado de forma independiente.