Volver

2026/11/04

CVE-2026-98432: use-after-free en TCP de Linux, root remoto asistido por IA mediante MPTCP y defensas para Linux empresarial

Una carrera en TCP IPv4 de Linux, un root remoto demostrado vía MPTCP y las correcciones y mitigaciones para RHEL, Ubuntu, Oracle Linux y Debian.

Información verificada: 3 de noviembre de 2026 | Análisis técnico de LOGIQ

En octubre de 2026 se divulgó una vulnerabilidad de tipo use-after-free (UAF), CVE-2026-98432, en la gestión de conexiones TCP IPv4 del kernel Linux. El equipo de CVE del kernel Linux publicó su aviso el 15 de octubre. El 27 de octubre, Anthropic informó de que un modelo de investigación interno aún no publicado demostró la ejecución remota de comandos sin autenticación y con privilegios de root contra un servidor Linux con un listener MPTCP (Multipath TCP). Es fundamental no confundir las condiciones concretas de ese exploit con los riesgos más amplios de vulnerabilidad y denegación de servicio que afectan a los servicios TCP IPv4 habituales.

Puntos clave

  • El fallo es una condición de carrera en la gestión habitual de solicitudes de conexión TCP IPv4, presente desde Linux 4.4. MPTCP no es necesario para que exista el error.
  • La demostración de root remoto de Anthropic tuvo como objetivo un servidor con un listener MPTCP; otros servicios TCP siguen expuestos a caídas, denegación de servicio y corrupción de memoria.
  • Red Hat califica el problema como Critical (CVSS v3.1 9.8) y publicó kernels corregidos para RHEL 8, 9 y 10 el 1 de noviembre. Las correcciones de Ubuntu seguían en curso el 3 de noviembre.
  • Instale un kernel corregido aprobado por el proveedor, reinicie y confirme el kernel en ejecución. Las mitigaciones reducen la exposición, pero no sustituyen al parche.

Dónde se produce la condición de carrera

El problema afecta al three-way handshake de TCP IPv4. Las opciones IP que mantiene un request socket (ireq->ireq_opt) pueden transferirse al inet_opt del socket hijo durante tcp_v4_syn_recv_sock() sin copiarse. Si otra CPU está procesando un SYN retransmitido y construyendo un SYN/ACK mientras se destruye el socket hijo, la memoria de las opciones puede liberarse cuando todavía está en uso. Un acceso posterior por parte de funciones como ip_options_build() puede provocar un UAF.

Existe una condición de carrera relacionada en la migración de request sockets mediante net.ipv4.tcp_migrate_req=1 o BPF_SK_REUSEPORT_SELECT_OR_MIGRATE, en la que los datos de opciones pueden compartirse entre el request socket original y el clonado. El comportamiento vulnerable se remonta a Linux 4.4, pero la exposición real debe evaluarse para cada kernel de proveedor, incluidos los backports.

El commit de corrección upstream e3f33b0a1d89 (“ipv4: free inet_opt and ireq_opt after an RCU grace period”) cambia la liberación inmediata en inet_sock_destruct() y tcp_v4_reqsk_destructor() por una liberación diferida mediante RCU a través de kfree_rcu(). El aviso de CVE de Linux indica correcciones en las versiones de kernel 6.12.113, 6.18.56, 7.2.10 y 7.3-rc7. La ruta IPv6 inicial no es la misma vulnerabilidad, aunque una ruta de migración IPv6 relacionada con CALIPSO se corrige con un parche independiente.

No confunda el root remoto demostrado con la exposición general

La prueba de concepto de Anthropic se dirigió a un servidor con un listener MPTCP y combinó una fuga de información de direcciones del kernel con el secuestro del flujo de control. Según lo publicado, el experimento tardó unos 48 minutos en obtener la fuga de información y otros cinco minutos en lograr la ejecución de comandos. Como una carrera perdida solo hace fallar el handshake en lugar de bloquear el sistema, el atacante puede seguir reintentándolo. Sin embargo, el UAF subyacente está en la gestión habitual de solicitudes de conexión TCP IPv4, no exclusivamente en el código de MPTCP.

La misma técnica de exploit de root remoto no se ha demostrado para todos los servicios TCP convencionales sin MPTCP. Aun así, también es incorrecto suponer que desactivar MPTCP hace que un sistema sea completamente seguro. Red Hat indica que MPTCP no es una condición necesaria, que los sistemas con MPTCP desactivado (el valor predeterminado) siguen afectados, y advierte de caídas remotas sin autenticación, denegación de servicio y corrupción de memoria en servicios TCP IPv4 estándar.

Evaluaciones principales de los proveedores: gravedad y estado de la corrección

Estado comprobado el 3 de noviembre de 2026. Las páginas de los proveedores cambian; consulte siempre la entrada actual antes de actuar.

ProveedorGravedadEstado de la corrección
Red HatCritical, CVSS v3.1 9.8Kernels corregidos publicados el 1 de noviembre: RHEL 8 (RHSA-2026:93414; kernel-rt para NFV RHSA-2026:93415), RHEL 9 (RHSA-2026:93412), RHEL 10 (RHSA-2026:93413). El kernel-rt de RHEL 9 y OpenShift (RHCOS) siguen figurando como Affected. RHEL 6 y 7 no están afectados.
UbuntuPrioridad High; CVSS 9.8linux para 26.10, 26.04, 24.04 y 22.04: Vulnerable, work in progress. 20.04, 18.04 y 16.04: Vulnerable. Todavía no se ha publicado ningún paquete corregido.
Oracle LinuxImportant; CVSS provisional 8.1Errata de UEK con fecha 16 de octubre (ELSA-2026-500397, -500398, -500399) para OL7 a OL10. Errata de RHCK con fecha 2 de noviembre para OL8 (ELSA-2026-93414) y OL10 (ELSA-2026-93413); aún no figura ninguna errata de RHCK para OL9.
Debian(Security Tracker)Corregido en bookworm 6.1.190-1 (DLA-4841-1), bookworm linux-6.12 6.12.113-1~deb12u1 (DLA-4850-1) y trixie 6.12.113-1 (DSA-6568-1); forky y sid corregidos.

Red Hat (evaluación revisada el 30 de octubre; boletín actualizado por última vez el 2 de noviembre). La página oficial de la CVE califica el problema como Critical, CVSS v3.1 9.8, porque un atacante remoto sin autenticación puede corromper la memoria del kernel o bloquear un sistema mediante tráfico TCP IPv4 normal. RHEL 8, 9, 10 y OpenShift figuran como afectados; el kernel de RHEL 7 figura como no afectado porque no contiene el código en cuestión. Desde el 1 de noviembre, los datos de CVE de Red Hat incluyen kernels corregidos: kernel-4.18.0-553.182.1.el8_10 (RHEL 8), kernel-5.14.0-687.64.1.el9_8 (RHEL 9) y kernel-6.12.0-211.72.1.el10_2 (RHEL 10). El boletín de seguridad RHSB-2026-016 seguía marcado como en curso y es donde se describe el procedimiento de mitigación. No presente puntuaciones antiguas de fuentes secundarias, como 5.9 u 8.1, como la evaluación actual de Red Hat.

Ubuntu (tabla oficial actualizada por última vez el 30 de octubre). El CVSS de la CVE es 9.8, mientras que la prioridad propia de Ubuntu es High. Los paquetes linux estándar de Ubuntu 26.10, 26.04, 24.04 y 22.04 están marcados como “Vulnerable, work in progress”, con las versiones de corrección previstas indicadas en la página; 20.04 figura como Vulnerable, entre otros estados. Las variantes de kernel AWS, Azure, HWE, RT y otras deben evaluarse por separado. “Work in progress” no significa que se haya publicado una corrección.

Oracle Linux. La evaluación propia de Oracle es Important, con una puntuación CVSS provisional de 8.1. Las errata de UEK para OL7, OL8, OL9 y OL10 tienen fecha del 16 de octubre, y las errata de RHCK para OL8 y OL10 llegaron el 2 de noviembre. Las correcciones en UEK no deben generalizarse a RHCK ni a todas las versiones menores; evalúe el kernel instalado y la errata exacta.

Debian. El Security Tracker oficial marca como corregidos, entre otros, bookworm-security 6.1.190-1 y trixie-security 6.12.113-1. Verifique tanto las versiones de los paquetes instalados como el kernel en ejecución tras el reinicio.

Los resultados de CVSS pueden diferir entre la CNA y los proveedores debido a configuraciones y correcciones propias de cada distribución, y las evaluaciones pueden cambiar. Registre siempre la fecha de verificación y enlace cada fuente oficial.

Medidas defensivas: la mitigación no sustituye al parche

La primera prioridad es instalar un kernel corregido aprobado por el proveedor y verificar la versión en ejecución después del reinicio. Cuando todavía no haya una corrección disponible, considere cerrar los servicios TCP públicos innecesarios, restringir las redes de origen permitidas y priorizar la monitorización de los hosts expuestos.

El boletín de Red Hat describe una mitigación con nftables que descarta los paquetes TCP IPv4 entrantes que llevan opciones IP en la cabecera IPv4:

table inet cve_2026_98432 {
  chain input {
    type filter hook input priority -310; policy accept;
    ip protocol tcp ip hdrlength > 5 counter drop
  }
}

No es una protección completa, puede afectar a cargas de trabajo que dependen de opciones IP y debe probarse su impacto en el tráfico de negocio antes de desplegarla. Las opciones TCP normales de la cabecera TCP siguen permitidas; no se trata de bloquear el campo TCP Options. En OpenShift, las reglas a nivel de nodo no filtran el tráfico entre pods dentro de la red del clúster, por lo que en ese caso es importante filtrar en el perímetro de la red. Elimine la tabla en cuanto el kernel corregido esté en ejecución.

Consejo: Después de aplicar el parche, compare uname -r con la versión corregida que indica la errata de su proveedor y guarde esa salida junto con el registro de cambios. Un paquete instalado con el que todavía no se ha arrancado no cierra la vulnerabilidad.

En Linux, el paquete net de Go, a partir de Go 1.24, activa MPTCP de forma predeterminada para los listeners. El equipo de Go documenta GODEBUG=multipathtcp=0 como forma de desactivarlo (también disponible como línea godebug en go.mod). Una propuesta para cambiar el valor predeterminado sigue en debate, y los mantenedores de Go señalan un kernel parcheado como la solución real. Este ajuste puede reducir la exposición a la ruta de ataque dependiente de MPTCP demostrada por Anthropic, pero no corrige el UAF del kernel en sí. Revise el uso de MPTCP servicio por servicio.

La perspectiva de LOGIQ

En el mantenimiento de Linux empresarial no se puede determinar la seguridad solo a partir de una puntuación CVSS pública o de uname -r. Evalúe en conjunto la versión del sistema operativo, la familia de kernel (por ejemplo, UEK o RHCK), la versión del paquete, el kernel con el que se ha arrancado, la exposición de red, la configuración de MPTCP, las errata del proveedor y la evidencia del reinicio. Haga un seguimiento de toda la cadena, desde la evaluación del impacto y la validación hasta el despliegue y la monitorización operativa.

Cuando las correcciones del proveedor estén pendientes, documente el riesgo residual de las mitigaciones temporales y vuelva a evaluarlas cuando lleguen los parches. A medida que la IA aumenta la explotabilidad práctica de las vulnerabilidades, el mantenimiento empresarial debe cubrir todo el ciclo de vida: detección, verificación, corrección y evidencia de un funcionamiento correcto.

Fuentes primarias y referencias