Claude ha creado un exploit de acceso root remoto para un fallo de TCP en Linux 9.8 que aún no se ha corregido en RHEL y Ubuntu

Principales conclusiones

• La vulnerabilidad CVE-2026-98432 permite a un atacante remoto provocar un «use-after-free» durante el protocolo de establecimiento de conexión TCP IPv4 en Linux.
• Anthropic afirma que un modelo de Claude aún no publicado lo convirtió en un exploit de root remoto contra los listeners de MPTCP.
• Upstream lo corrigió el 5 de octubre, pero los núcleos basados en RHEL y Ubuntu aún no cuentan con las correcciones.
• A partir de la versión 1.24 de Go, MPTCP está habilitado de forma predeterminada en los sockets de escucha, pero en las versiones EL 8, 9 y 10, MPTCP permanece desactivado.

La versión resumida

Ir a la versión completa ↓

Qué ocurrió: El 15 de octubre de 2026, el equipo de CVE del núcleo publicó el CVE-2026-98432, una condición de carrera de «uso tras liberación» en el código que gestiona los handshakes TCP de IPv4, y le asignó una puntuación CVSS de 9,8 el 24 de octubre. La corrección, de dos líneas, se aplicó en el código original el 5 de octubre y está presente en todas las ramas estables mantenidas. El investigador de Anthropic, Xinyang Ge, fue quien lo notificó. Ir a esta sección →

La afirmación: El 27 de octubre, Anthropic afirmó que un modelo de investigación interno de Claude, aún no publicado, había creado un exploit funcional que permite a un atacante remoto sin credenciales ejecutar comandos como root en servidores Linux que cuenten con un listener de Multipath TCP (MPTCP). El código del exploit, la versión del kernel y la configuración probada no se han hecho públicos, y hasta el 30 de octubre no se había producido ninguna reproducción pública independiente. Ir a esta sección →

Quiénes se ven afectados: cualquier núcleo de Linux a partir de la versión 4.4 que no haya incorporado la corrección, en un servidor que acepte conexiones TCP IPv4. Esto incluye RHEL 8, 9 y 10 y las distribuciones basadas en ellas, además de Ubuntu. RHEL 7 y CentOS 7 no se ven afectados, y las conexiones IPv6 no provocan el fallo principal. Ir a esta sección →

Por qué es importante MPTCP: los programas escritos en Go con la versión 1.24 o posterior habilitan MPTCP en sus sockets de escucha de forma predeterminada. Sin embargo, las versiones EL 8, 9 y 10 se suministran con MPTCP desactivado, por lo que un host EL de serie no puede abrir un listener MPTCP a menos que alguien lo haya activado. El equipo de seguridad de Go sigue afirmando que los sistemas sin un listener MPTCP pueden ser vulnerables a ataques similares. Ir a esta sección →

Situación actual: No se trata de una vulnerabilidad de día cero. La corrección se publicó antes del CVE, Anthropic no ha publicado su código de explotación y, a fecha de 30 de octubre, no se ha notificado ningún caso de explotación en el mundo real y el fallo no figura en el catálogo KEV de la CISA. Debian, Oracle UEK, la mayoría de las versiones de SUSE con soporte técnico y algunos núcleos de Amazon Linux ya están corregidos. Red Hat y Ubuntu aún no han lanzado un núcleo corregido ni han dado una fecha. El parche sin reinicio de KernelCare ya está disponible para Debian 13, y se están compilando parches para EL 8, 9 y 10 sin esperar a Red Hat. Ir a esta sección →

Qué hacer hoy: Averigua si hay algún servicio en tus servidores que utilice MPTCP. Con -H Si se omite la fila de encabezado, cada línea que muestra este comando corresponde a un listener de MPTCP:

ss -H -lMn

En los servidores que no tengan un núcleo fijo, el descarte de paquetes TCP entrantes que contengan opciones IP debería bloquear el desencadenante documentado, independientemente de si se utiliza MPTCP o no. No se ha probado, así que pruébalo primero en el entorno de pruebas. Ir a esta sección →

La mayoría de los fallos del núcleo a los que se puede acceder a través de la red tienen una trampa. Es necesario cargar un módulo, activar un protocolo especializado o tener en ejecución un servicio que casi nadie utiliza. El CVE-2026-98432 se encuentra en el código que acepta conexiones TCP IPv4. Si un servidor admite conexiones TCP IPv4, ejecuta este código.

Solo por eso, un 9.8 ya merecería la pena echarle un vistazo. Lo que lo llevó a los titulares fue la afirmación de Anthropic de que uno de sus modelos lo convirtió en un exploit de acceso root remoto sin necesidad de credenciales. El propio CVE se había publicado discretamente doce días antes, uno de los muchos que el equipo de CVE del kernel publica cada semana.

Lo complicado es el calendario. Upstream lo solucionó el 5 de octubre. Debian ya había publicado un kernel corregido el 16 de octubre. Red Hat aún no tiene ninguno para RHEL 8, 9 ni 10, y ese retraso, más que el aspecto relacionado con la IA, es lo que determina cuánto tiempo permanecerán expuestos los sistemas empresariales afectados.

El desencadenante es un paquete TCP SYN que lleva opciones IPv4, concretamente Registrar ruta o marca de tiempo. El tráfico normal casi nunca envía estos datos, pero nada impide que un cliente lo haga. El núcleo en modo escucha guarda esas opciones junto con la solicitud de conexión pendiente, en ireq_opt.

Cuando finalice el intercambio de datos, tcp_v4_syn_recv_sock() transfiere las opciones al nuevo socket hijo sin crear una copia, por lo que el socket de solicitud y el hijo ahora apuntan a la misma memoria. Si el cliente reenvía su SYN en el momento adecuado, otra CPU puede recoger ese SYN retransmitido y empezar a generar un SYNACK a partir de las mismas opciones en ip_options_build(). Si, mientras tanto, se desmonta el enchufe secundario, inet_sock_destruct() libera las opciones con un simple kfree(), y la ruta SYNACK lee memoria que ya no existe.

El error se remonta a la confirmación 079096f103fa («tcp/dccp: incorporar las solicitudes syn_recv a la tabla ehash»), lo que permite procesar los sockets de solicitud sin mantener el bloqueo del listener. Esa confirmación se incluyó en Linux 4.4 en enero de 2016. Red Hat indica que RHEL 7 no se ve afectado, y CentOS 7 utiliza la misma versión del núcleo.

En solución La corrección de Eric Dumazet es de lo más breve que puede ser una corrección del núcleo. Una kfree() en inet_sock_destruct() en net/ipv4/af_inet.c y uno en tcp_v4_reqsk_destructor() en net/ipv4/tcp_ipv4.c convertirse en kfree_rcu(), por lo que cualquier proceso que siga leyendo las opciones finaliza antes de que se libere la memoria. La primera es la función «free» que interviene en la ruta principal, y la segunda se aplica a la ruta de migración que se describe a continuación.

Existe una segunda vía, más limitada, que pasa por la migración de los sockets de solicitud, y que solo se aplica en el caso de net.ipv4.tcp_migrate_req=1 o un BPF_SK_REUSEPORT_SELECT_OR_MIGRATE programa adjunto. Ambos están desactivados por defecto. Si has leído que este error «requiere una configuración diferente a la predeterminada», eso solo es cierto para la ruta de migración. La ruta principal no necesita ninguna.

IPv6 evita la ruta principal porque tcp_v6_syn_recv_sock() copia las opciones. El Registro CVE También señala un problema de migración similar en lo que respecta a IPv6, limitado a las opciones establecidas por CALIPSO, y el equipo de desarrollo tiene previsto lanzar un parche independiente para ese problema.

Es difícil ganar la carrera, pero eso no es tan tranquilizador como parece. Una carrera perdida simplemente supone el fracaso de ese único intercambio de datos. No provoca un fallo en el servidor, por lo que un atacante puede seguir intentándolo mientras el puerto permanezca abierto.

Anthropic describió el exploit en una publicación del 27 de octubre de su equipo Frontier Red Team, junto con cadenas de exploits para Chrome, Safari, Android y Windows. La publicación indica que el trabajo utilizó un modelo de investigación interno aún no publicado, y que el modelo escribió el exploit para Linux tras una «indicación inicial».

Anthropic describe dos etapas. En primer lugar, al ganar la carrera, el núcleo lee un campo de longitud controlado por el atacante y copia bytes adicionales en el SYNACK que devuelve; y, una vez que una de esas respuestas contiene un puntero al núcleo, se elude el KASLR. En segundo lugar, el mismo fallo provoca un desbordamiento de búfer y sobrescribe un puntero de devolución de llamada con la dirección de una carga útil ya preparada en la memoria del núcleo. Cuando el núcleo llama a ese puntero sobrescrito, se ejecuta como root un comando de shell elegido por el atacante. Anthropic afirma que la fuga de direcciones tardó 48 minutos en su prueba, y que la ejecución del comando tardó otros cinco.

TuxCare no ha reproducido el exploit y, a fecha de 30 de octubre, no se había dado a conocer ninguna reproducción pública independiente. Anthropic no ha publicado el código, la versión del núcleo ni la configuración con la que realizó las pruebas. La publicación tampoco aclara si los servidores que no cuentan con un listener MPTCP pueden ser comprometidos de la misma manera.

Sin embargo, esta afirmación no contradice lo que ya había escrito el equipo de CVE del núcleo. Las propias notas de evaluación del equipo en el registro CVE describen cómo las opciones obsoletas filtran memoria adyacente del montón del núcleo de vuelta al par y provocan escrituras fuera de límites en el núcleo. La cadena de Anthropic es, básicamente, esa descripción puesta en práctica.

MPTCP permite que una conexión utilice varias rutas de red a la vez. En Linux, una aplicación solo puede acceder a esta función si la solicita al abrir un socket, por lo que, durante años, la mayoría de los equipos podían dar por hecho con total seguridad que no la estaban utilizando.

Go cambió eso. Desde la versión 1.24 de Go, los programas de Go en Linux activan MPTCP de forma predeterminada en los sockets de escucha, siempre que el núcleo lo admita. Una pasarela de API, un proxy inverso o un servicio interno basado en Go y creado con Go 1.24 o una versión posterior podría estar ejecutando un listener MPTCP que sus propietarios nunca solicitaron.

Las tiendas de EL reciben aquí buenas noticias. Red Hat se suministra con RHEL con la compatibilidad con MPTCP desactivada, y las versiones recompiladas se distribuyen de la misma forma, por lo que activarlo implica configurar net.mptcp.enabled=1 Tú mismo. En un servidor EL 8, 9 o 10 de serie, un servicio Go solicita MPTCP, el núcleo lo rechaza y el servicio recurre silenciosamente a un listener TCP sencillo. A menos que alguien de tu equipo haya activado MPTCP, la cadena que ha demostrado Anthropic no tiene ningún objetivo al que dirigirse.

El 29 de octubre, el Equipo de seguridad de Go dicha configuración GODEBUG=multipathtcp=0 en el entorno de un programa desactiva esa configuración predeterminada en tiempo de ejecución, y al añadir godebug multipathtcp=0 al módulo principal go.mod hace lo mismo durante la compilación. El código que llama a SetMultipathTCP en un net.ListenConfig o net.Dialer anula ambas. El equipo también calificó esta medida como una mitigación frágil, ya que basta con que un solo oyente MPTCP quede expuesto para que el sistema siga siendo vulnerable. Y fue un paso más allá: el fallo subyacente no es específico de MPTCP, por lo que los sistemas que no cuenten con oyentes MPTCP podrían ser vulnerables a ataques similares.

De todos modos, planifica teniendo en cuenta ese último punto. Nadie ha demostrado públicamente haber obtenido privilegios de root en un servidor sin un listener MPTCP, y la cadena de explotación demostrada necesita uno. Sin embargo, se puede acceder al propio fallo a través de cualquier listener TCP IPv4, y el equipo de Go no descarta otras vías, por lo que un host con MPTCP desactivado está menos expuesto, pero no está protegido.

Si sysctl net.mptcp.enabled devoluciones 1, las aplicaciones de ese host pueden abrir sockets MPTCP. En EL 8, 9 y 10, 0 es el valor por defecto. En una versión razonablemente reciente de iproute2, ss -H -lMn muestra los oyentes MPTCP que existen realmente, sin la fila de encabezado. Si ss rechaza el -M indicador: el iproute2 de ese servidor es demasiado antiguo para esta comprobación.

Por qué los proveedores no se ponen de acuerdo en una puntuación

El equipo de CVE del núcleo asigna a CVE-2026-98432 una puntuación de 9,8, con un vector de ataque de red, sin privilegios y una complejidad de ataque baja. Su razonamiento se basa en que ambos lados de la carrera son «inducidos por el atacante», ya que este controla el SYN, la retransmisión y la desconexión. La página de Ubuntu muestra la misma puntuación de 9,8. A fecha de 30 de octubre, el NVD aún no había añadido su propia puntuación.

Red Hat partió de una valoración mucho más baja. En su página de CVE, la vulnerabilidad se clasificó inicialmente como «Moderada» (5,9), con un fallo del sistema como consecuencia más probable y sin que se hubiera demostrado ningún impacto en la confidencialidad o la integridad. El 29 de octubre, su archivo de aviso legible por máquina pasó a «Importante» (8,1), con un alto impacto en la confidencialidad y la integridad, y el 30 de octubre la página de CVE mostraba el mismo 8,1. Oracle, SUSE y Amazon también le otorgan una puntuación de 8,1.

Toda esa diferencia restante se reduce a un único indicador. El vector 8.1, común a Red Hat, Oracle, SUSE y Amazon, coincide con el del equipo del núcleo en todos los aspectos, salvo en la complejidad del ataque, que esos proveedores califican como alta. Se trata de una observación técnica válida sobre una carrera. Sin embargo, tiene menos importancia cuando perder la carrera no le cuesta al atacante más que un intento de conexión.

El problema práctico radica en la configuración. Si tu escáner o parche SLA se basa en la clasificación de gravedad del proveedor, es posible que esta vulnerabilidad haya aparecido en los servidores EL como «Moderada», o que ni siquiera se haya considerado urgente, durante la mayor parte del mes de octubre, a pesar de que se había descrito públicamente una cadena de acceso remoto con privilegios de root. Si tu proceso clasifica los parches según la gravedad del proveedor, anula esa configuración para este CVE.

CloudLinux 9 y 10 utilizan núcleos de AlmaLinux, por lo que siguen la línea de AlmaLinux. Red Hat menciona el problema para RHEL 8, 9 y 10, pero no indica ninguna fecha de lanzamiento, y Ubuntu tampoco lo hace.

Si compilas tus propios núcleos, la corrección se incluye en las versiones estables mencionadas anteriormente. El equipo de CVE del núcleo recomienda actualizar al último núcleo estable en lugar de seleccionar correcciones individuales.

A fecha de 30 de octubre, Red Hat afirma que ninguna medida de mitigación disponible cumple sus estándares, y ningún otro proveedor menciona ninguna en sus avisos. Las opciones que se indican a continuación se derivan del funcionamiento del fallo, pero ninguna de ellas se ha probado internamente frente a un ataque. Prueba cada una de ellas primero en un servidor de pruebas y no las consideres un sustituto de un kernel corregido.

La opción de mayor alcance consiste en descartar los paquetes TCP entrantes que contengan opciones IPv4. La ruta principal necesita opciones IP en el paquete SYN; el tráfico TCP normal no las incluye, y a esta regla no le importa si algún proceso del host utiliza MPTCP:

nft add table ip cve_2026_98432
nft add chain ip cve_2026_98432 prerouting '{ type filter hook prerouting priority -300; }'
nft add rule ip cve_2026_98432 prerouting meta l4proto tcp ip hdrlength != 5 drop

Para deshacerlo, ejecuta nft delete table ip cve_2026_98432. La regla no se mantiene tras un reinicio, así que añádela a tu configuración persistente del cortafuegos si decides mantenerla. El filtrado de opciones IP en el perímetro de la red puede abarcar todos los hosts que se encuentran detrás, siempre y cuando todo el tráfico dirigido a dichos hosts pase efectivamente por ese perímetro. El inconveniente es que cualquier cliente TCP que envíe opciones IP queda bloqueado, aunque ese tipo de tráfico es poco frecuente.

Los ingenieros de TuxCare han revisado la regla y parece correcta. Sin embargo, al no existir ninguna prueba de concepto pública con la que contrastarla, todavía no hay nada con lo que probarla.

En segundo lugar, comprueba que la ruta de migración esté cerrada. sysctl net.ipv4.tcp_migrate_req debería volver 0, que es el valor predeterminado, y el servidor no debería tener un BPF_SK_REUSEPORT_SELECT_OR_MIGRATE programa adjunto.

En tercer lugar, y como solución más rápida, desactiva MPTCP en cualquier host que no lo necesite. Ejecuta sysctl -w net.mptcp.enabled=0, y pon net.mptcp.enabled = 0 en un archivo dentro de /etc/sysctl.d/ para que se mantenga así. Las versiones EL 8, 9 y 10 ya se distribuyen de esa forma, por lo que esto solo es relevante en las distribuciones que mantienen la configuración predeterminada del desarrollador original de 1, y en los servidores EL en los que alguien haya activado MPTCP. Reinicia los servicios que ya hayan abierto escuchas MPTCP para que vuelvan a funcionar con TCP estándar. En el caso de los servicios Go, GODEBUG=multipathtcp=0 Hace lo mismo en cada programa. Elimina la necesidad de la cadena del oyente Anthropic, pero no soluciona el error.

Si un servidor está conectado a Internet y no tiene un kernel fijo, empieza por comprobar net.mptcp.enabled y desactivar MPTCP si no es necesario. Se trata de un único ajuste de sysctl, es fácil de revertir y elimina el listener del que depende la cadena demostrada. La regla de opciones IP es la siguiente capa que hay que evaluar. Pruébala en el entorno de pruebas, confirma que elimina lo que esperas sin causar ningún problema y, a continuación, decide si la implementas. En cualquier caso, da prioridad a ese host a la hora de recibir un kernel corregido. Si tu distribución ya incluye un kernel corregido, instálalo, reinicia el sistema o aplica el parche que permite la actualización sin reinicio, y omite las soluciones provisionales.

Comprobar un servidor en menos de un minuto

Cinco comandos responden a la mayoría de las preguntas:

uname -r
sysctl net.mptcp.enabled net.ipv4.tcp_migrate_req
ss -H -lMn
nft list table ip cve_2026_98432
kcarectl --patch-info | grep 'CVE-2026-98432'

La primera línea muestra el núcleo en ejecución, pero los núcleos de EL y Ubuntu incluyen adaptaciones de versiones anteriores que el número de versión no revela, por lo que debes comparar el paquete del núcleo instalado con el aviso de tu proveedor y la tabla anterior. A 1 para net.mptcp.enabled significa que las aplicaciones pueden abrir sockets MPTCP, y net.ipv4.tcp_migrate_req debería ser 0, el valor por defecto. Cada línea ss -H -lMn prints es un listener MPTCP. El nft Esta línea muestra la tabla y sus reglas, si están cargadas, para que puedas comprobar que la regla de eliminación está realmente ahí, y la última línea indica si KernelCare ha aplicado su parche sin necesidad de reinicio para este CVE. Se trata de indicadores rápidos, no de una prueba de seguridad completa. Para una flota, ejecuta las mismas líneas a través de cualquier herramienta que ya gestione tus comandos ad hoc, ya sea Ansible, Salt o simplemente ssh en un bucle.

La posición de KernelCare

Ya está disponible el parche de KernelCare para CVE-2026-98432 sin necesidad de reiniciar para Debian 13, tanto en los canales de producción como en los de ePortal. Los parches para Debian 12 y Oracle Linux UEK están en proceso de desarrollo. La corrección del desarrollador original es pequeña y no modifica ninguna estructura de datos, por lo que TuxCare no está a la espera de Red Hat. Actualmente se están compilando parches que no requieren reinicio para los núcleos de EL 8, 9 y 10 en RHEL, AlmaLinux, CloudLinux, Oracle Linux RHCK y Rocky Linux, y el CVE Tracker los mostrará a medida que se publiquen. Los parches para Ubuntu aún no están disponibles y no hay una fecha prevista.

En Debian 13, los servidores con actualizaciones automáticas de KernelCare obtienen el parche según su calendario habitual, o bien puedes descargarlo inmediatamente con kcarectl --update. No es necesario reiniciar. Comprueba que se haya instalado con kcarectl --patch-info | grep 'CVE-2026-98432'. El Rastreador de CVE de TuxCare Muestra el estado de los parches que no requieren reinicio por distribución, a medida que va cambiando.

Consigue KernelCare hoy mismo →

La solución llegó primero, pero sigue sin ser suficiente

Según los criterios habituales, esta divulgación se ha llevado a cabo correctamente, aunque todavía hay muchos servidores Linux empresariales a la espera.

La divulgación coordinada cumplió su función en las fases iniciales. La corrección se implementó antes de que se publicara el CVE, el CVE se publicó antes de que nadie afirmara haber encontrado un exploit, y el código del exploit en sí permaneció en la esfera privada. Nadie puede calificar esto como un «día cero».

Nada de eso ayuda a un servidor web RHEL 9 con el puerto 443 abierto. Una corrección de dos líneas en el código fuente aún tiene que convertirse en una compilación del kernel del proveedor, luego en un paquete distribuido y, finalmente, en un reinicio o un parche sin reinicio en cada host expuesto. En el caso de RHEL y las distribuciones que lo recompilan, ese primer paso aún no se había producido a fecha de 30 de octubre. Mientras tanto, un artículo público describe ahora la estructura de una cadena de ataque que funciona y cuánto tiempo llevó cada etapa. El código se mantuvo privado, pero el enfoque no, y el próximo intento no tendrá que empezar desde cero.

Así que comprueba qué hosts tienen listeners MPTCP, sobre todo los que estén escritos en Go, y desactiva MPTCP allí donde no sea necesario. Prueba la regla de opciones IP en el entorno de pruebas y, si funciona correctamente, plantéate aplicarla a los servidores expuestos a Internet que no tengan un kernel fijo. A continuación, estate atento a los kernels fijos de tu distribución y calcula cuánto tardarás en implementarlos en todos los hosts expuestos —ya sea mediante un parche sin reinicio o reiniciando el sistema, lo que tu parque de servidores pueda tolerar realmente—.

Consigue KernelCare hoy mismo →

Fuentes

Las fuentes principales de esta entrada son el anuncio de CVE del núcleo, el registro CVE y la corrección del desarrollador original, además de las páginas de los proveedores Red Hat (incluidos su aviso de seguridad y su sistema de seguimiento de errores), Ubuntu, Debian, Oracle, Amazon y SUSE. También se citan la entrada de Anthropic, el anuncio del equipo de seguridad de Go, la documentación GODEBUG de Go, la documentación sobre MPTCP del núcleo, la entrada del NVD, la cobertura de The Hacker News y los registros de lanzamientos de KernelCare de TuxCare a fecha de 30 de octubre de 2026.