CVE-2026-98432: un fallo TCP del kernel Linux abre la puerta a root remoto en servidores MPTCP

Una vulnerabilidad crítica de tipo use-after-free en la pila TCP IPv4 del kernel Linux, registrada como CVE-2026-98432, puede convertirse en ejecución remota de código como root, sin autenticación, en servidores que aceptan conexiones Multipath TCP (MPTCP). Ya se ha demostrado un exploit funcional, y los parches están llegando de forma desigual a las principales distribuciones.

Qué ha ocurrido

El error es una condición de carrera en la forma en que el kernel procesa las solicitudes de conexión TCP. Cuando una conexión pasa de solicitud pendiente a socket completo, el kernel entrega el búfer de opciones IP al nuevo socket sin conservar una copia propia. Si en ese mismo instante otro núcleo de CPU está atendiendo un SYN retransmitido para la misma solicitud, esa segunda ruta de código puede seguir leyendo memoria que ya ha cambiado de dueño: un use-after-free clásico. Existe una ventana similar durante la migración de sockets de solicitud, cuando está activado net.ipv4.tcp_migrate_req o se usa un programa BPF_SK_REUSEPORT_SELECT_OR_MIGRATE.

Datos clave:

Afectados: kernels Linux desde la versión 4.4, incluidas las compilaciones de Ubuntu, Red Hat Enterprise Linux y Rocky Linux.
Gravedad: 9,8/10 en la puntuación del equipo CVE del kernel Linux. Red Hat la puntúa más bajo, con 5,9, y la trata sobre todo como riesgo de caída del kernel (denegación de servicio), porque ganar la carrera es difícil.
RCE probado: un exploit de demostración —generado por un modelo de IA aún no publicado— eludió la aleatorización del espacio de direcciones del kernel (KASLR) y ejecutó comandos arbitrarios como root en un servidor con un listener MPTCP, en condiciones específicas, en unos 53 minutos.
El TCP convencional también está afectado, aunque no se ha demostrado públicamente la ejecución remota de código en servidores sin listener MPTCP.
Sin explotación confirmada en entornos reales en el momento de escribir este artículo.
No afectados: macOS (otro kernel) y RHEL 7 (no contiene el código vulnerable).

Por qué importa

MPTCP permite que una única conexión use varias rutas de red a la vez —por ejemplo, Wi-Fi y datos móviles— y normalmente está desactivado salvo que la aplicación lo solicite. El problema: desde Go 1.24, los listeners TCP en Linux activan MPTCP por defecto siempre que el kernel lo admita. Cualquier servicio escrito en Go podría estar exponiendo un listener MPTCP sin que sus administradores lo hayan activado nunca.

También conviene fijarse en la diferencia entre ambas puntuaciones. Una carrera difícil de ganar no es imposible de ganar, y una demostración pública que convierte un «fallo que provoca caídas» en root remoto en menos de una hora muestra lo rápido que se acortan los plazos de explotación, sobre todo a medida que madura el desarrollo de exploits asistido por IA.

Estado de los parches (a 30 de octubre de 2026)

Kernel upstream: corregido y retroportado a las ramas estables mantenidas.
Debian: corregido en el kernel 6.1.190-1 (Debian 12 «Bookworm») y 6.12.113-1 (Debian 13 «Trixie»); testing e unstable también están corregidas.
Ubuntu: 22.04 LTS, 24.04 LTS, 26.04 LTS y 26.10 siguen siendo vulnerables, con correcciones del kernel en curso.
RHEL 8, 9, 10 / Rocky Linux 8, 9, 10: afectados; las correcciones están previstas en próximas actualizaciones.
Oracle Linux, Amazon Linux, SUSE: correcciones disponibles para algunas versiones del kernel.

Qué hacer

Primero, parchear. Siga los avisos de seguridad de su distribución e instale los paquetes del kernel actualizados en cuanto estén disponibles; después reinicie o confirme que su live-patching cubre este CVE.
Localice su exposición a MPTCP. Ejecute ss -Mtln para listar los listeners MPTCP y compruebe sysctl net.mptcp.enabled. Preste especial atención a los servicios compilados con Go 1.24 o posterior.
No confíe solo en desactivar MPTCP. El fallo de fondo sigue siendo alcanzable mediante TCP convencional, así que desactivar MPTCP reduce la vía de RCE demostrada, pero no elimina el error.
Filtre donde aún no pueda parchear. Limite los servicios expuestos a redes o rangos IP de confianza. Como medida temporal, descarte en el cortafuegos del host o del perímetro (por ejemplo, con nftables) los paquetes TCP IPv4 entrantes que lleven opciones IP: el tráfico legítimo casi nunca las usa. Pruébelo antes de desplegarlo de forma generalizada.
Revise la configuración de migración. Si no la necesita, mantenga net.ipv4.tcp_migrate_req desactivado y audite los programas BPF de tipo reuseport.
Vigile las caídas. Los kernel panic o mensajes «oops» inexplicables en código TCP de hosts expuestos a internet merecen una investigación, no solo un reinicio.

Saber cuáles de sus hosts expuestos a internet siguen ejecutando un kernel vulnerable —y cuáles exponen discretamente servicios que no esperaba— es justo el tipo de brecha que nuestro servicio de escaneo de vulnerabilidades está diseñado para sacar a la luz, para que el esfuerzo de parcheo vaya donde está la exposición real.