CVE-2026-98432: falla de Linux permitió acceso como root

CVE-2026-98432: falla de Linux permitió acceso como root

CVE-2026-98432 permite acceso remoto como root; actualiza Linux y no dependas solo de desactivar MPTCP.

Por Humberto Toledo el 31 de octubre del 2026 a las 1:29 pm PDT

✨︎ Resumen (TL;DR):

  • Anthropic informó que un modelo de investigación de Claude desarrolló una prueba para explotar CVE-2026-98432 sin credenciales ni intervención del usuario.
  • El ensayo tardó unos 48 minutos en obtener información de la memoria del kernel y otros 5 minutos en ejecutar un comando.
  • Linux ya incorporó una corrección, pero el estado del parche cambia según la distribución; desactivar MPTCP no sustituye actualizar el kernel.

Anthropic informó que un modelo de investigación de Claude desarrolló el método después de recibir instrucciones iniciales. La prueba funcionó contra un servidor con Multipath TCP (MPTCP) expuesto a la red y permitió ejecutar comandos a distancia como root, sin credenciales ni intervención del usuario. La corrección ya llegó al proyecto Linux, pero eso no significa que cada proveedor la haya distribuido para todos sus productos.

CVE-2026-98432 es una vulnerabilidad del kernel de Linux ubicada en el código que procesa conexiones IPv4 TCP. Aparece cuando operaciones concurrentes acceden a una zona de memoria que el sistema ya liberó.

MPTCP es un protocolo que permite que una conexión utilice varias rutas de red. El ejemplo de Anthropic requirió MPTCP, pero el defecto subyacente también afecta al TCP convencional. El equipo de seguridad del lenguaje Go advirtió que no se puede descartar que sistemas sin MPTCP sean vulnerables a ataques similares.

Claude cambia Max 20x por Ultra y quita límite de 5 horas
Te podría interesar:
Claude cambia Max 20x por Ultra y quita límite de 5 horas

La prueba llegó hasta la cuenta root

En el servidor de prueba, Anthropic consiguió que el código se ejecutara como root, la cuenta con los mayores privilegios del sistema. Un atacante que alcanzara ese nivel podría controlar el equipo afectado.

Anthropic informó el 27 de octubre que su ensayo tardó unos 48 minutos en obtener información de la memoria del kernel y otros 5 minutos en ejecutar un comando. Esos tiempos describen esa prueba y no garantizan el mismo resultado en otras configuraciones.

Por separado, la compañía presentó en octubre OSS Scanner, un servicio que busca fallas en proyectos de código abierto y envía informes a sus mantenedores para que los evalúen.

El parche no llega igual a todas las distribuciones

Anthropic indicó que el proyecto Linux incorporó una corrección al kernel y la llevó a las ramas estables mantenidas. Esa incorporación no significa que todos los proveedores ya la hayan distribuido para cada uno de sus productos.

Al consultar los registros el 31 de octubre, el seguimiento de seguridad de Debian mostraba paquetes corregidos para Debian 12, conocido como Bookworm, y Debian 13, llamado Trixie.

Actualizada el 30 de octubre, la ficha de Ubuntu todavía marcaba como vulnerable el paquete principal del kernel de Ubuntu 22.04 LTS, 24.04 LTS, 26.04 LTS y 26.10, con correcciones en curso. Canonical asignó al problema una puntuación CVSS 3 de 9.8 sobre 10.

Red Hat clasificó la falla como crítica en un boletín del 30 de octubre. La compañía señaló que afecta a Red Hat Enterprise Linux 8, 9 y 10, además de OpenShift Container Platform, y dijo que aceleraba la publicación de correcciones.

Desactivar MPTCP no basta

El equipo de seguridad de Go explicó que, desde Go 1.24, los programas en Linux habilitan MPTCP por defecto para los servicios que esperan conexiones, cuando el sistema lo admite. La configuración de cada aplicación puede cambiar ese comportamiento.

Desactivar MPTCP por aplicación es una medida frágil: podría quedar algún servicio expuesto y la falla no se limita a ese protocolo. La recomendación principal del equipo es actualizar a una versión del kernel que incluya la corrección.

Red Hat señaló que filtrar el tráfico relacionado puede reducir la exposición mientras llegan los parches, pero la medida puede interferir con servicios necesarios y no sustituye la actualización. El estado de protección debe comprobarse para la distribución y versión concretas del servidor.

El administrador debe comprobar el estado de protección de la distribución y versión concretas del servidor y actualizar a un kernel que incluya la corrección. Filtrar tráfico puede reducir la exposición mientras llega el parche, pero desactivar MPTCP por aplicación no sustituye la actualización y podría dejar algún servicio expuesto.

Fuentes: 1, 2, 3, 4, 5, 6

+ Temas Relacionados

Más de Tecnología

Feed