- Una condición de carrera y use-after-free en TCP IPv4 del kernel Linux dispara las alertas, con puntuaciones de gravedad muy dispares entre fabricantes.
- Anthropic afirmó que Claude generó un exploit funcional contra un servidor con MPTCP, sin publicar el código ni confirmar ataques reales.
- Debian, Oracle y parte de Amazon y SUSE ya publicaron correcciones; Ubuntu y RHEL seguían pendientes en varias ramas al cierre de la información.
- Actualizar el kernel del proveedor y reiniciar es la única solución fiable; desactivar MPTCP solo reduce el vector demostrado.
El kernel de Linux ha vuelto a colocarse en el centro de las conversaciones de seguridad por un problema que afecta al corazón de las conexiones de red. Se trata de CVE-2026-98432, un fallo en el tratamiento de TCP sobre IPv4 que puede desembocar en un uso de memoria ya liberada, conocido como use-after-free. La cosa no se queda en un aviso técnico: varias distribuciones han tenido que mover ficha, y la aparición de un exploit desarrollado con ayuda de inteligencia artificial ha añadido una capa de urgencia.
Lo llamativo del asunto es que no estamos ante un error de una aplicación concreta ni ante una configuración mal puesta. El fallo vive en el propio kernel, en la rutina que atiende el saludo inicial de una conexión TCP. Ahí es nada. Esa zona trabaja antes de que un servidor web, una base de datos o una API lleguen a ver un solo byte del tráfico. Por eso el aviso ha cruzado de largo el terreno de los administradores de sistemas: afecta a servidores expuestos, a infraestructura cloud y a máquinas virtuales que comparten kernel con otros servicios. No es solo un titular, aunque conviene separar la gravedad técnica del ruido mediático.
Qué falla exactamente en el TCP del kernel
El origen está en una condición de carrera durante el handshake TCP IPv4. Cuando llega una petición de conexión, el kernel guarda ciertas opciones asociadas al paquete y las conserva para responder. En paralelo, otra CPU puede seguir leyendo esa información mientras una parte del sistema decide liberar la memoria. Si las operaciones se cruzan en el momento justo, aparece el use-after-free: el núcleo intenta trabajar con una zona que ya no le pertenece. Eso puede provocar desde un cuelgue hasta corrupción de memoria o un comportamiento difícil de predecir.
El arreglo aplicado en las ramas estables cambia la forma de liberar esa memoria para esperar a que terminen los lectores. La corrección se apoya en un periodo de gracia y evita que el kernel suelte las opciones demasiado pronto. Hay un dato que explica el sobresalto: el código vulnerable se arrastra desde Linux 4.4, así que ha pasado años escondido en versiones muy extendidas. No todas las configuraciones están expuestas de la misma manera, pero la superficie potencial es enorme porque hablamos de la pila de red del sistema.
Otro matiz importante: IPv6 no reproduce la misma carrera en el camino principal. El código de IPv6 copia las opciones antes de utilizarlas, por lo que la condición concreta no se da igual. Eso no significa que el resto del mundo pueda dormirse, porque la mayoría de servidores siguen conviviendo con IPv4 y porque un error en Linux puede poner en jaque la seguridad de miles de servidores. La recomendación general sigue siendo la misma: comprobar el estado del fabricante y aplicar el paquete corregido.
El exploit de Claude y el matiz de MPTCP
La historia dio un giro cuando Anthropic afirmó que Claude escribió un exploit funcional para este fallo. La empresa asegura que el modelo identificó la vulnerabilidad y generó una cadena capaz de ejecutar comandos con privilegios de root contra un servidor Linux con un listener de Multipath TCP. El hallazgo se atribuye a Xinyang Ge, investigador de Anthropic. Eso sí, fue una prueba de laboratorio y el código no se hizo público, así que no estamos ante una herramienta lista para copiar y pegar en cualquier servidor.
El ataque descrito tenía dos fases. Primero, el exploit aprovechaba la carrera para filtrar información de memoria y romper KASLR, la aleatorización de direcciones del kernel. En las pruebas, obtener una dirección válida llevó unos 48 minutos. Después, con esa información en la mano, la segunda fase manipulaba estructuras internas para redirigir la ejecución hacia una carga útil. Ejecutar comandos como root necesitó unos cinco minutos adicionales. Son tiempos de laboratorio, no un cronómetro universal, pero sirven para entender que el fallo puede pasar de un simple crash a algo bastante más serio en determinadas condiciones.
Conviene no perder de vista que el exploit no se ha publicado y que no constan ataques reales asociados a este CVE. Tampoco aparecía en el catálogo de vulnerabilidades explotadas de forma conocida de CISA al cierre de la información. Ahora bien, que no haya pruebas públicas de uso no convierte el fallo en inocuo. La demostración de Anthropic basta para que los equipos de seguridad revisen sus servidores, sobre todo si tienen servicios expuestos a internet y kernels de distribuciones que aún no han recibido el parche.
Aquí entra en juego MPTCP, pero con cuidado: MPTCP no es la raíz del problema. Multipath TCP fue la característica presente en el escenario que Anthropic consiguió explotar, pero el error de fondo está en el manejo general de TCP IPv4. El equipo de seguridad de Go advirtió además de que, desde Go 1.24, los programas de Go pueden activar MPTCP por defecto en los sockets donde escuchan. Para reducir ese vector se puede usar GODEBUG=multipathtcp=0 en el entorno o añadir godebug multipathtcp=0 en el go.mod. Aun así, la propia recomendación es clara: desactivar MPTCP es una mitigación frágil, porque basta un listener expuesto para dejar el sistema vulnerable.
Por qué las notas de gravedad no coinciden
El equipo CNA del kernel firmó una puntuación de 9,8 sobre 10 en CVSS 3.1, lo que coloca el fallo en la categoría crítica. Esa nota asume un ataque remoto, sin credenciales y sin interacción del usuario, con impacto potencial en confidencialidad, integridad y disponibilidad. Sobre el papel, el escenario es feo: un paquete TCP manipulado podría desencadenar la carrera y abrir la puerta a consecuencias graves. Por eso muchas distribuciones lo han señalado como prioritario.
Sin embargo, las fichas de los fabricantes no son uniformes. Red Hat ha llegado a publicar 5,9 como moderada en una de sus evaluaciones, argumentando que ganar la carrera exige una sincronización complicada y que el resultado más probable dentro de sus productos es un cuelgue del kernel. En cambio, su aviso legible por máquinas y otros proveedores como Oracle o SUSE manejan 8,1. Amazon ha oscilado entre 7,0 y 8,1, y Ubuntu marca prioridad alta, con 9,8 en CVSS 3.1 y 8,3 en CVSS 4.0.
La diferencia no es un capricho ni una guerra de números: está en la complejidad del ataque. El equipo del kernel considera que el atacante controla ambos lados de la carrera y que puede reintentar; varios fabricantes creen que la ventana es más estrecha y que el impacto demostrado en sus configuraciones es más limitado. Las dos lecturas pueden coexistir. Para un administrador, la consecuencia práctica es que no conviene guiarse por una sola cifra: hay que mirar qué kernel corre, qué servicios están expuestos y qué aviso ha publicado su distribución.
Qué distribuciones tienen parche y cuáles van con retraso
El panorama cambia rápido, pero al cierre de esta información Debian y Oracle Linux ya contaban con paquetes corregidos. Debian publicó actualizaciones para sus ramas mantenidas, mientras que Oracle distribuyó erratas para su Unbreakable Enterprise Kernel. Son dos casos relativamente adelantados, aunque cada administrador debe comprobar la versión exacta y la errata que le corresponde, porque no todos los kernels de una misma familia reciben el arreglo al mismo tiempo.
El caso de Ubuntu 22.04, 24.04, 26.04 y 26.10 seguía marcado como vulnerable o con trabajo en curso en varias fichas de seguridad. También aparecían afectados kernels especiales de nube, FIPS y tiempo real. Eso significa que un simple apt upgrade no resuelve nada hasta que Canonical publique el paquete correspondiente para cada rama. Mientras llega, toca revisar la exposición y no confundir un kernel nuevo instalado con un kernel nuevo en ejecución.
En Red Hat, RHEL 8, 9 y 10 figuran como afectados, igual que los núcleos de tiempo real y los nodos RHEL CoreOS usados por OpenShift 4. RHEL 6 y 7 no están afectados porque su kernel no contiene el código vulnerable. Al cierre de la información, varias ramas de RHEL seguían sin paquete corregido listado, con los arreglos diferidos a una actualización futura. Es un punto delicado para entornos empresariales y servicios cloud que no pueden reiniciar a la ligera.
Amazon Linux y SUSE presentan una situación mixta. Amazon Linux 2023 ya tenía correcciones para algunas ramas recientes, como kernel6.18 y kernel6.12, mientras que el paquete kernel por defecto y todo Amazon Linux 2 seguían pendientes. En SUSE, algunos productos ya disponían de paquetes, como SLES 16.0 y determinados kernels LTSS de la rama 15, mientras otros estaban en proceso de QA o pendientes de actualización.
Si se compila el kernel a mano, las ramas upstream corregidas incluyen 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 y 7.3. Pero Ojo: en un servidor empresarial no conviene instalar un kernel suelto de kernel.org solo porque el número aparezca en la lista. Ubuntu, RHEL, SUSE, Oracle y Amazon mantienen sus propias ramas con backports, firma y soporte. Comparar uname -r con una tabla genérica puede llevar a conclusiones equivocadas.
Qué hacer sin liarla: parche, reinicio y mitigaciones temporales
La primera medida sensata es instalar el kernel del fabricante en cuanto esté disponible. No vale cualquier versión: debe ser la que el proveedor de la distribución marque como corregida para ese producto concreto. Si el sistema usa live patching, hay que confirmar que el CVE está cubierto por esa vía; si no, toca planificar la ventana de mantenimiento. Para saber qué hay instalado, uname -r muestra el kernel en ejecución y lsb_release -a ayuda a identificar la versión de la distribución en Ubuntu.
Después de actualizar hay que reiniciar de verdad. Un paquete nuevo no cambia el código que ya está cargado en memoria. Si existe /var/run/reboot-required, el sistema está pidiendo un reinicio. Tras el arranque, conviene volver a ejecutar uname -r y comprobar que el número coincide con la versión corregida que indique el fabricante. En clústeres y entornos cloud, el reinicio debe hacerse nodo a nodo, con cuidado de no tumbar el servicio, pero sin dejar hosts antiguos campando a sus anchas.
Un error habitual es creer que los contenedores no aíslan este problema. Docker, Podman y Kubernetes comparten el kernel del anfitrión. Actualizar la imagen de la aplicación no cambia el kernel del nodo. Si el host está vulnerable, el contenedor también respira sobre un kernel vulnerable. Por eso el parche va en los nodos, en las máquinas virtuales y en los appliances que traen su propio kernel, no solo en la capa de aplicación.
Mientras llega el parche, desactivar MPTCP puede reducir la exposición al exploit concreto que se ha demostrado, pero no corrige el fallo de fondo. El equipo de seguridad de Go lo califica como una mitigación frágil: cualquier listener que se deje activo puede mantener la puerta abierta. Tampoco conviene olvidar que el error subyacente no es específico de MPTCP, así que apagar esa función no debería venderse como solución definitiva.
Otra medida temporal es filtrar opciones IPv4 en el borde de la red. El tráfico TCP legítimo rara vez lleva opciones IPv4, así que descartar paquetes con una longitud de cabecera superior a la habitual puede servir de puente. Red Hat ha ofrecido una mitigación de cortafuegos para paquetes TCP IPv4 entrantes con opciones IP, y también se ha propuesto una regla nft que actúe antes del connection tracking. Son parches de emergencia, no sustitutos del kernel corregido, y conviene probarlas contra las cargas de trabajo antes de desplegarlas a lo loco.
La fotografía que queda es la de un fallo serio en una pieza que casi nadie mira hasta que se rompe. La única solución fiable sigue siendo aplicar el kernel corregido del proveedor y reiniciar para que el cambio entre en vigor. El exploit de laboratorio de Claude ha demostrado que la velocidad de la seguridad ofensiva ya no es la de hace unos años, pero también ha dejado claro que la respuesta sensata no es improvisar cambios en el kernel, sino saber qué versión corre en cada servidor, qué servicios están expuestos y cuándo toca actualizar. Quien tenga esa lista a mano lo llevará mucho mejor que quien descubra el problema a mitad del incendio.