Ciberseguridad · Aviso

Núcleo (kernel) de Linux — pila de red TCP/IPv4 · Uso de memoria tras liberación explotable en remoto

Un fallo crítico en la pila TCP/IPv4 del kernel de Linux permite, en teoría, que un atacante remoto sin credenciales lea memoria, bloquee el servidor o ejecute código; ya hay parche oficial, pero algunas distribuciones aún no lo han publicado.

Publicado 1 noviembre 2026 Lectura 9 min Ref. CVE-2026-98432 CVSS 9.8 (Autoridad de numeración (CNA) del kernel de Linux, CVSS 3.1 = 9,8 (Crítica). Red Hat también lo valora como Crítico 9,8 desde el 30 de octubre de 2026 (antes lo había puntuado como 8,1). NVD aún figura como «Received», sin análisis propio.)

Resumen

CVE-2026-98432 es un fallo de tipo use-after-free (uso de memoria después de haberla liberado) en el código con el que el kernel de Linux establece las conexiones TCP entrantes por IPv4. Lo puede alcanzar un atacante remoto sin autenticarse, antes de que intervenga ninguna aplicación. La CNA del kernel lo puntúa con CVSS 9,8 (Crítica) y Red Hat lo ha elevado también a Crítico. Existe parche corregido en las versiones estables del kernel desde el 11-15 de octubre de 2026, pero a 1 de noviembre de 2026 Ubuntu y Red Hat Enterprise Linux (RHEL) todavía no habían liberado un kernel corregido. No consta explotación activa en el mundo real: el único exploit descrito es una prueba de concepto no publicada atribuida a Anthropic.

Materias: Vulnerabilidades, Kernel de Linux, Redes y TCP/IP, Administración de sistemas, Gestión de parches, Protección de datos y RGPD

Un error en una de las piezas más básicas y universales de Linux —el código que acepta las conexiones de red TCP por IPv4— ha recibido la máxima categoría de gravedad. Identificado como CVE-2026-98432, permite, al menos sobre el papel, que cualquiera en la red provoque desde una caída del servidor hasta la ejecución de código con privilegios de administrador, sin necesidad de usuario ni contraseña. El parche oficial ya existe; el problema, a 1 de noviembre de 2026, es que no todas las distribuciones lo han publicado todavía.

Descripción

Qué es. CVE-2026-98432 es una vulnerabilidad de tipo use-after-free en el kernel (el núcleo del sistema operativo, la capa que gestiona el hardware, la memoria y la red) de Linux. «Use-after-free» significa literalmente «uso después de liberar»: el programa libera un trozo de memoria —lo marca como disponible para otros usos— pero sigue leyéndolo o escribiéndolo después, cuando su contenido ya puede haber cambiado o estar ocupado por otra cosa. Es una de las familias de fallos de memoria más peligrosas (se corresponde con la debilidad catalogada como CWE-416, «Use After Free»; el registro también la ha asociado a CWE-825, «Expired Pointer Dereference»).

El fallo está en la pila TCP/IPv4, es decir, en el código que negocia las conexiones de red entrantes sobre el protocolo IP versión 4. Afecta a este mismo código en su función de recibir conexiones; las conexiones por IPv6 no están afectadas por el problema principal (el propio parche indica que el caso de IPv6 «se abordará en un parche aparte»).

A quién afecta. A prácticamente cualquier equipo Linux que acepte conexiones TCP por IPv4: servidores web, servidores SSH, bases de datos, balanceadores de carga y nodos de Kubernetes. Como los contenedores comparten el kernel de la máquina anfitriona, un contenedor «nuevo» no cambia nada: lo que cuenta es el kernel del host. La exposición es independiente de la aplicación, porque el código vulnerable se ejecuta durante el saludo inicial de la conexión (handshake), antes de que ningún programa ni ninguna autenticación entren en juego.

A qué versiones afecta. El error existe desde Linux 4.4 en adelante. Está corregido, en las ramas estables oficiales, a partir de: 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 y 7.3. Las versiones anteriores a 5.10 que ya habían llegado al fin de su vida útil («end-of-life») no reciben corrección oficial y dependen de los parches que publique cada distribución. Aviso importante: las distribuciones numeran sus kernels con sus propios esquemas, así que no debe compararse con el número de versión «de arriba» (upstream), sino consultarse el rastreador («tracker») de seguridad de la distribución concreta.

Mecánica

Cómo funciona el fallo

Cuando un servidor Linux recibe una conexión TCP, el kernel no crea de golpe toda la estructura de la conexión. Primero anota el saludo a medio completar en un objeto ligero llamado request socket («socket de petición») y, cuando el handshake termina, construye el socket completo. Si la cabecera IPv4 del paquete entrante traía «opciones» (campos adicionales del protocolo, como Record Route o Timestamp), el kernel se guarda esas opciones para poder reflejarlas en sus respuestas.

El error está ahí: el kernel pasaba esas opciones guardadas desde el request socket a la nueva conexión sin hacer una copia propia y, cuando la conexión desaparecía, liberaba esa memoria de inmediato (kfree()) mientras otra CPU podía seguir leyéndola para construir una respuesta del saludo (por ejemplo, al reenviarse un paquete SYN). Leer memoria del kernel ya liberada es, exactamente, un use-after-free.

Según las notas de puntuación de la CNA, ese dato «caducado» puede provocar tres cosas: que se filtre contenido de la memoria dinámica (heap) del kernel hacia el atacante remoto, que se corrompa memoria del kernel desviando escrituras fuera de los límites previstos, o que la máquina se bloquee. Red Hat, en su boletín, afirma que un atacante remoto y no autenticado «podría explotar una condición de carrera durante el procesamiento de la solicitud de conexión TCP para desencadenar ejecución remota de código».

El papel de MPTCP y el contexto de la prueba de concepto

Anthropic, cuya investigación dio origen al aviso, sostiene que su modelo Claude escribió un exploit funcional que ejecuta órdenes como root (administrador) sobre «servidores Linux con un listener de multipath TCP», sin credenciales. MPTCP (multipath TCP) es una extensión de TCP que permite usar varias rutas de red a la vez. Conviene separar lo confirmado de lo que solo es afirmación de una parte: el exploit no se ha publicado y el registro CVE ni siquiera menciona MPTCP. Anthropic no ha explicado por qué ese listener resulta necesario para su exploit.

Lo que sí está documentado es que el equipo de seguridad de Go indica que, «a partir de Go 1.24, los programas Go activan MPTCP por defecto para los sockets de escucha en Linux», lo que hace que la configuración que el exploit necesita sea más frecuente de lo que parecía. El propio equipo de Go matiza, además, que «el fallo subyacente no es específico de MPTCP» y que es posible que sistemas sin listeners MPTCP sean vulnerables a ataques similares. Dicho de otro modo: MPTCP facilita el camino demostrado, pero el fallo está en el código TCP/IPv4 corriente y todos los sistemas afectados necesitan el parche.

Respuesta del creador

Respuesta del mantenedor y de las distribuciones

El fallo lo corrigió Eric Dumazet con el commit «ipv4: free inet_opt and ireq_opt after an RCU grace period», revisado por Kuniyuki Iwashima. Lo reportó Xinyang Ge, de Anthropic. El registro CVE lo emitió la propia CNA del kernel de Linux y se publicó el 15 de octubre de 2026.

La corrección cambia dos llamadas de liberación directa (kfree()) por kfree_rcu(), que espera a que todos los lectores hayan terminado de usar la memoria antes de liberarla (el mecanismo RCU, Read-Copy-Update, del kernel). El mismo commit arregla el problema equivalente en la migración de request sockets (net.ipv4.tcp_migrate_req=1).

Red Hat publicó el boletín RHSB-2026-016, elevó la gravedad a Crítico (CVSS 9,8) el 30 de octubre —antes la tenía en 8,1— «por la ausencia de requisitos de red y por el potencial de inestabilidad grave del sistema», y afirma que «está acelerando la publicación de las correcciones». SUSE la clasifica como «important»; Ubuntu, como «High»; Oracle y Amazon, como «Important» con CVSS 8,1. La diferencia de puntuaciones entre fabricantes es normal: cada uno valora el riesgo en el contexto de sus propios productos.

Autoridades. A 1 de noviembre de 2026, la vulnerabilidad no figura en el catálogo de vulnerabilidades explotadas conocidas (KEV) de CISA, y no consta explotación activa en el mundo real confirmada por el fabricante ni por fuentes fiables: el único exploit descrito es la prueba de concepto no publicada de Anthropic. El NVD estadounidense aún mostraba el registro como «Received», sin análisis propio.

Parches y mitigaciones

Qué hacer ya

1. Actualizar el kernel y reiniciar. Instale el kernel corregido de su distribución en cuanto esté disponible y reinicie: una actualización del kernel no surte efecto hasta que la máquina arranca con él. Hay que reiniciar también los anfitriones de contenedores y los nodos de Kubernetes. No se compare con el número de versión «upstream»: consulte el rastreador de su distribución.

Estado por distribución (a 1 de noviembre de 2026)

Ya tienen parche: Debian 12 «bookworm» y 13 «trixie»; SUSE Linux Enterprise Server 16.0 y las ramas 15 LTSS (SP4, SP5, SP6); openSUSE Leap 16.0; el kernel UEK de Oracle Linux (errata de octubre); y todos los kernels de Amazon Linux 2 y 2023.
En pruebas: AlmaLinux 8, 9 y 10 tienen kernels corregidos en su repositorio de pruebas (testing) desde el 30 de octubre, pendientes de pasar a producción tras la validación de la comunidad.
Todavía sin parche: Ubuntu (el rastreador marca «Vulnerable» en todas las versiones; en 26.10, 26.04, 24.04 y 22.04 indica «work in progress», pero no se había publicado aún un aviso de seguridad) y Red Hat Enterprise Linux 8, 9 y 10 y OpenShift (figuran como afectados sin corrección). Conviene vigilar sus rastreadores.

Si todavía no puede parchear: mitigación provisional

El tráfico TCP legítimo casi nunca lleva opciones IPv4, así que descartar los paquetes TCP que las traen bloquea el desencadenante sin apenas coste. Es la regla que recomiendan Red Hat y AlmaLinux. No es un arreglo (Red Hat advierte de que «reduce la exposición pero no la impide por completo») y no sustituye al parche; además, no persiste tras un reinicio.

Con nftables:

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

La condición ip hdrlength gt 5 casa con cualquier cabecera IPv4 de más de 20 bytes, que es justo lo que producen las opciones. Para eliminarla tras parchear: nft delete table ip cve_2026_98432. Si su cortafuegos perimetral puede descartar paquetes IPv4 con opciones, hacerlo ahí protege a todos los equipos situados detrás.

Medidas adicionales: desactive MPTCP si no lo usa (compruebe sysctl net.mptcp.enabled; un valor 0 impide abrir sockets MPTCP) y priorice el parcheo de los hosts que sí tengan listeners MPTCP (puede listarlos con ss -Mlnp). Recuerde que desactivar MPTCP por sí solo no elimina la vulnerabilidad, porque el fallo está en el TCP/IPv4 corriente.

Apunte para responsables jurídicos

Al tratarse de una vulnerabilidad en una pieza tan universal, la diligencia debida (due diligence) exige dejar constancia del inventario de sistemas afectados, de las fechas de parcheo y de las mitigaciones aplicadas. Un fallo de este tipo no es por sí mismo una brecha de datos, pero si llegara a explotarse con acceso a datos personales podrían activarse las obligaciones de notificación del RGPD (notificación a la autoridad de control en un máximo de 72 horas, art. 33, y comunicación a los afectados, art. 34). Mantener un registro de la gestión de este aviso ayuda a demostrar la responsabilidad proactiva.