Un atacante remoto, sin necesidad de usuario ni contraseña, puede leer memoria del kernel, corromperla o tumbar el servidor con solo enviarle paquetes de conexión TCP. Así describe la autoridad de numeración del propio kernel de Linux a la CVE-2026-98432, una falla crítica que el proyecto corrigió con un parche de apenas cuatro líneas, pero que sigue sin solución en Ubuntu y en Red Hat Enterprise Linux, dos de las plataformas más usadas por empresas y gobiernos de México y América Latina.
El problema importa porque no requiere interacción de la víctima ni credenciales: basta con que el servidor acepte conexiones TCP sobre IPv4. La autoridad del kernel le asignó 9.8 sobre 10 en CVSS 3.1, la nota máxima para un fallo explotable de forma remota y sin autenticación. Red Hat elevó su propia calificación a Critical el 30 de octubre, mientras el rastreador de Ubuntu mantenía marcado el paquete linux como vulnerable en todas sus versiones soportadas, sin aviso de seguridad publicado.
Qué es la CVE-2026-98432 y por qué es tan grave
Se trata de un use-after-free en el código que procesa el saludo TCP sobre IPv4. El kernel libera la memoria que guarda las opciones IP de una solicitud de conexión y, por una condición de carrera, otra ruta del código todavía puede leerla o escribirla después de liberada. Ese patrón clásico de descoordinación entre dos caminos de ejecución permite exponer contenido del heap del kernel al par remoto, corromper memoria o colgar la máquina.
El bug vive desde la versión 4.4, lanzada en 2016, y arrastra por tanto una década de historial. La primera versión afectada es la 4.4, y solo queda fuera de alcance la rama de 4.4 a 5.4 porque ya llegó a su fin de vida upstream y no recibirá parche oficial del proyecto Linux; las distribuciones que aún la mantienen deben portar la corrección por su cuenta.
El parche definitivo cambia solo cuatro líneas en el subsistema de red del kernel: mueve la liberación de la memoria a después del período de gracia de RCU, el mecanismo que usa el kernel para saber cuándo ya nadie más está leyendo una estructura antes de borrarla. El commit se titula «ipv4: free inet_opt and ireq_opt after an RCU grace period», lo firma Eric Dumazet y lo revisó Kuniyuki Iwashima, dos de los mantenedores habituales del subsistema de red.
Las versiones corregidas del kernel estable son 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 y 7.3. El registro se publicó en cve.org el 15 de octubre y el parche se liberó el 11 y el 15 de octubre de 2026. IPv6 no está afectado por este problema en particular, porque esa pila de red no comparte el mismo camino de opciones IP.
El estado real de las distribuciones
No todas las distribuciones van atrasadas, y esa diferencia es clave para las áreas de infraestructura en la región. Al 31 de octubre de 2026, el panorama era el siguiente:
- Ubuntu: vulnerable en todas las versiones soportadas, sin kernel corregido todavía.
- Red Hat Enterprise Linux 8, 9 y 10, junto con OpenShift Container Platform: afectados, con calificación elevada a Critical el 30 de octubre, pero sin kernel corregido disponible.
- AlmaLinux 8, 9 y 10: kernel corregido en su repositorio de pruebas desde el 30 de octubre, un día antes que Red Hat, de quien deriva su base.
- Amazon Linux: todos sus kernels ya corregidos.
- Debian, SUSE Enterprise y Oracle UEK: kernels parchados desde antes de que Red Hat subiera la calificación.
La vulnerabilidad la reportó Xinyang Ge, investigador de Anthropic. La compañía afirma que su modelo Claude escribió un exploit que otorga acceso root remoto sin necesitar ninguna credencial, aunque no publicó el código de la prueba de concepto.
Multipath TCP: el factor que amplía el riesgo
Lo que amplía el riesgo real es Multipath TCP (MPTCP), la extensión que permite combinar varias rutas de red en una sola conexión. El exploit que construyó Claude necesita, según Anthropic, «servidores Linux con un listener multipath TCP» y ninguna credencial.
El equipo de seguridad de Go advierte que los programas escritos en ese lenguaje abren ese tipo de listener por defecto. Es decir, la configuración que requiere el ataque es más común de lo que parecía al principio: no depende de que un administrador la haya activado a propósito. Cualquier servidor que corra un binario de Go con un listener TCP podría tener multipath TCP activo sin que nadie lo haya pedido.
La ventana de ataque tampoco depende de ninguna aplicación en particular, porque el saludo TCP se procesa dentro del kernel antes de que la conexión llegue a cualquier programa de espacio de usuario. La falla alcanza a cualquier servidor, físico o virtual, que use un kernel 4.4 o posterior sin el parche, y eso incluye a los contenedores: un contenedor comparte el kernel del host, así que una imagen nueva no cambia nada si la máquina que la ejecuta sigue vulnerable.
Cómo saber si tu infraestructura está expuesta
Lo primero es revisar el rastreador de tu propia distribución, porque los números de versión no coinciden entre el kernel upstream y el que empaqueta cada distribución. Para confirmar si tu kernel ya tiene el parche, ejecuta uname -r y compáralo contra la tabla de versiones corregidas: un resultado como 6.12.113-generic ya incluye la corrección si el número coincide o es posterior al listado.
En Ubuntu Pro, el comando pro fix CVE-2026-98432 --dry-run indica directamente si el paquete instalado sigue expuesto. Mientras llega el parche, Red Hat propone una mitigación con nftables en su boletín RHSB-2026-016, y los analistas sugieren una regla provisional: descartar los paquetes TCP que llevan opciones IPv4.
Ambas opciones cortan también tráfico legítimo que use esas opciones, así que conviene aplicarlas solo mientras llega el kernel definitivo. Si no usas multipath TCP, desactivarlo reduce la superficie de ataque sin tocar el resto del tráfico; si lo usas, prioriza parchear esos hosts primero.
Lo que este episodio dice sobre la IA en ciberseguridad
El caso deja un dato incómodo sobre el estado de la inteligencia artificial en seguridad: la misma falla crítica que un investigador humano reportó terminó con una prueba de concepto escrita por un modelo, capaz de convertir un bug remoto en acceso root sin usuario ni contraseña. Que un modelo pueda llegar a ese resultado cambia el cálculo de cuánto tiempo pasa entre que se conoce un bug y que alguien lo convierte en un arma.
Para las organizaciones de México y América Latina que operan infraestructura crítica sobre Ubuntu o Red Hat, la recomendación es clara: revisar el estado del kernel contra el rastreador de la distribución, aplicar la regla de nftables del boletín de Red Hat mientras llega el parche definitivo y no asumir que los contenedores están protegidos solo por estar actualizados.