Una vulnerabilidad crítica en el kernel de Linux, identificada como CVE-2026-98432, ha puesto en alerta a administradores de sistemas de todo el mundo. El fallo, un use-after-free en el código que procesa el saludo TCP sobre IPv4, permite a un atacante remoto no autenticado leer memoria del kernel, corromperla o provocar una denegación de servicio. Aunque el kernel upstream ya publicó un parche de cuatro líneas, distribuciones mayores como Ubuntu y Red Hat Enterprise Linux (RHEL) aún no han liberado actualizaciones corregidas, dejando expuestos a miles de servidores en México y América Latina.
¿Qué es CVE-2026-98432 y por qué es tan grave?
La vulnerabilidad afecta al kernel de Linux desde la versión 4.4, lanzada en 2016. El problema reside en el manejo de las opciones IP durante el establecimiento de una conexión TCP. Cuando llega un paquete SYN con opciones IPv4, el kernel crea un request socket temporal y almacena esas opciones en dos punteros: inet_opt e ireq_opt. Si la solicitud expira o se procesa fuera de orden, una ruta del código libera esa memoria; si casi simultáneamente otra ruta intenta completar el saludo TCP con el ACK final, se produce una condición de carrera que deriva en un use-after-free. Un atacante puede explotar esta situación para acceder a memoria que ya debería estar liberada.
La autoridad de numeración del kernel le asignó una puntuación de 9.8 sobre 10 en CVSS 3.1, la máxima para un fallo que no requiere autenticación ni interacción del usuario. Las consecuencias van desde la exposición de contenido del heap del kernel hasta la corrupción de memoria o el colapso del servidor. IPv6 no se ve afectado por este problema en particular.
Estado de los parches: kernel upstream vs. distribuciones
El kernel estable de Linux publicó el parche el 11 y el 15 de octubre de 2026. Las versiones corregidas 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. Sin embargo, las distribuciones que empaquetan su propio kernel deben aplicar el fix de forma independiente.
Al 31 de octubre, la situación era dispar:
- Ubuntu: todas las versiones soportadas seguían marcadas como vulnerables, sin aviso de seguridad publicado.
- Red Hat Enterprise Linux (8, 9 y 10) y OpenShift Container Platform: afectados, con calificación elevada a Critical el 30 de octubre, pero sin kernel corregido disponible. Red Hat publicó una mitigación temporal en su boletín RHSB-2026-016.
- AlmaLinux (8, 9 y 10): ya cuenta con kernels corregidos en su repositorio de pruebas desde el 30 de octubre, un día antes que Red Hat.
- Amazon Linux: todos sus kernels están corregidos.
- Debian, SUSE Enterprise y Oracle UEK: también disponen de versiones parchadas desde antes de que Red Hat elevara la calificación.
Es importante notar que las ramas entre 4.4 y 5.4 han llegado a su fin de vida upstream y no recibirán parche oficial del proyecto Linux; las distribuciones que aún las mantienen deben portar el fix por su cuenta.
El exploit creado por inteligencia artificial
Un dato inquietante: la vulnerabilidad fue reportada por Xinyang Ge, investigador de Anthropic, y según la compañía, su modelo Claude escribió un exploit funcional que otorga acceso root remoto sin necesidad de credenciales. El exploit requiere que el servidor tenga un listener de Multipath TCP (MPTCP) activo, una extensión que combina varias rutas de red en una sola conexión. El equipo de seguridad de Go advierte que los programas escritos en ese lenguaje abren ese tipo de listener por defecto, lo que amplía significativamente la superficie de ataque. Anthropic no publicó el código del exploit, pero el hecho de que un modelo de IA haya logrado convertir un bug remoto en acceso root plantea nuevos desafíos para la ciberseguridad.
¿Cómo saber si tu servidor está afectado?
Lo primero es verificar la versión del kernel en ejecución con el comando uname -r y compararla con la tabla de versiones corregidas. Por ejemplo, un resultado como 6.12.113-generic ya incluye el fix si el número coincide o es posterior al listado. En Ubuntu Pro, el comando pro fix CVE-2026-98432 --dry-run indica si el paquete instalado sigue expuesto.
Mientras llega el parche definitivo, Red Hat propone una mitigación con nftables en su boletín RHSB-2026-016, que consiste en descartar los paquetes TCP que llevan opciones IPv4. Esta medida también corta tráfico legítimo que use esas opciones, por lo que debe aplicarse solo temporalmente. Si no se utiliza Multipath TCP, desactivarlo reduce la superficie de ataque sin afectar el resto del tráfico. Si se utiliza, se recomienda priorizar el parcheo de esos hosts.
Recomendaciones para administradores en Latinoamérica
Dada la gravedad de la falla y la falta de parches en Ubuntu y RHEL, se recomienda a las organizaciones revisar el estado de sus servidores y aplicar las mitigaciones disponibles. Además, es crucial monitorear los avisos de seguridad de cada distribución para actualizar tan pronto como se liberen los kernels corregidos. La exposición es especialmente crítica en entornos de nube y contenedores, ya que comparten el kernel del host; ninguna actualización dentro de la imagen del contenedor soluciona el problema si el kernel subyacente sigue vulnerable.