Saltar al contenido
CiberseguridadServidoresLinux

CVE-2026-98432: el fallo del kernel de Linux que permite atacar servidores por TCP, y qué hacer si usa Ubuntu

Por Abant SistemasPublicado el

CVE-2026-98432 es un fallo en el código del kernel de Linux que establece las conexiones TCP sobre IPv4, es decir, en lo primero que hace un servidor cuando alguien se conecta a él, antes de cualquier contraseña. Tiene una puntuación de 9,8 sobre 10, afecta a los kernels desde la versión 4.4 y lo puede aprovechar un atacante remoto sin credenciales. La corrección está en el kernel desde el 5 de octubre y el aviso es público desde el 15. Red Hat publicó sus parches el 1 de noviembre y Debian ya los tiene, pero Ubuntu, a 2 de noviembre, sigue sin un kernel corregido.

Si sus servidores llevan Ubuntu, hoy no hay nada que instalar. Lo que sí puede hacer es reducir lo que está expuesto a internet mientras llega el parche.

Qué ha pasado

El fallo es de los llamados uso después de liberar (use-after-free): durante el establecimiento de la conexión, el kernel libera una zona de memoria que todavía puede usarse. Si el atacante consigue ganar esa carrera, puede leer memoria del kernel o alterarla. Si pierde, solo falla esa conexión, así que puede repetir el intento tantas veces como quiera.

Lo reportó Xinyang Ge, investigador de Anthropic. El 27 de octubre, Anthropic explicó que un modelo interno de Claude, todavía no publicado, había escrito un exploit completo contra servidores Linux con un servicio que acepta conexiones Multipath TCP (MPTCP): en unos 48 minutos de intentos obtuvo una dirección de memoria del kernel y en unos minutos más ejecutó órdenes como administrador (root). Anthropic no ha publicado ese código, y CloudLinux ha dicho que no ha podido reproducir el resultado.

A 2 de noviembre no hay ataques reales confirmados y el fallo no figura en el catálogo de vulnerabilidades explotadas de CISA. Pero en GitHub ya hay decenas de repositorios que lo mencionan, algunos con intentos de prueba de concepto, y fundaciones como la de Solana han pedido a sus operadores que tomen medidas inmediatas.

¿Solo afecta a servidores con MPTCP?

Es la duda principal, y no está resuelta. El exploit de Anthropic necesitaba un servicio con MPTCP, una extensión de TCP que las aplicaciones tienen que pedir expresamente. Pero el fallo está en el código normal de TCP sobre IPv4, y ni el registro del CVE ni la corrección mencionan MPTCP. El equipo de seguridad del lenguaje Go considera posible que servidores sin MPTCP sean vulnerables a ataques parecidos. Además, los programas compilados con Go 1.24 o posterior piden MPTCP por defecto, así que puede haber servicios con MPTCP activo sin que nadie lo haya decidido.

Conclusión práctica: desactivar MPTCP reduce el riesgo del ataque demostrado, pero no sustituye al parche.

Qué distribuciones tienen ya el parche

DistribuciónEstado a 2 de noviembreKernel corregido
Debian 13 (trixie)Corregido6.12.113-1 (DSA-6568-1)
Debian 12 (bookworm)Corregido6.1.190-1
Red Hat Enterprise Linux 8, 9 y 10Corregido el 1 de noviembreRHSA-2026:93414, 93412 y 93413
Amazon Linux 2023Corregidokernel 6.12.113 y 6.18.56
Ubuntu 22.04, 24.04, 26.04 y 26.10Vulnerable, corrección en preparaciónSin publicar
Ubuntu 16.04, 18.04 y 20.04VulnerableSin fecha

Las distribuciones derivadas de Red Hat, como AlmaLinux o Rocky Linux, suelen publicar sus paquetes poco después; compruebe el aviso de la suya. Recuerde que un kernel nuevo no protege hasta que se reinicia el servidor, salvo que use un servicio de parcheo en caliente que ya incluya esta corrección.

A quién afecta en una pyme

A cualquier servidor Linux que acepte conexiones desde internet: el servidor privado virtual (VPS) donde está la web o la tienda online, el que aloja el ERP o la VPN, servidores de correo, máquinas con Docker y nodos de Kubernetes. Muchas pymes contrataron un VPS con Ubuntu hace años y nadie lo revisa desde entonces; esos son los primeros a mirar.

Muchos NAS, routers y cortafuegos también funcionan con Linux por dentro. En esos equipos el parche depende del fabricante, que suele tardar más que las distribuciones. Vigile sus avisos de seguridad y, mientras tanto, no publique sus servicios directamente en internet.

Qué hacer hoy

  1. Haga inventario de los servidores Linux con algún puerto abierto a internet y anote la distribución y la versión del kernel (comando uname -r).
  2. Si la distribución ya tiene parche (Debian, Red Hat, Amazon Linux), actualice el kernel y reinicie. Empiece por los servidores expuestos a internet.
  3. En Ubuntu, compruebe si algún servicio usa MPTCP y, si no lo necesita, desactívelo como medida provisional (comandos más abajo). En programas hechos en Go 1.24 o posterior, la variable GODEBUG=multipathtcp=0 hace que no lo pidan.
  4. Cierre todo lo que no tenga que estar abierto. El acceso de administración por SSH debería estar limitado a direcciones conocidas o detrás de una VPN, y las bases de datos no deberían escuchar en internet.
  5. Si su proveedor lo permite, ponga los servicios web detrás de un proxy o balanceador que termine las conexiones TCP, para que el kernel del servidor no reciba las conexiones directamente desde internet.
  6. Esté pendiente de la página del CVE en Ubuntu. En cuanto aparezca como corregido, actualice (apt update y apt full-upgrade) y reinicie.

Comprobar y desactivar MPTCP

Estos comandos muestran el kernel en uso, si MPTCP está activado y qué servicios aceptan conexiones MPTCP, y lo desactivan de forma persistente. Hágalo en una ventana de mantenimiento si el servidor es crítico:

uname -r
sysctl net.mptcp.enabled
ss -Mltn

# Desactivar MPTCP ahora y tras cada reinicio
sudo sysctl -w net.mptcp.enabled=0
echo "net.mptcp.enabled = 0" | sudo tee /etc/sysctl.d/99-sin-mptcp.conf

Cuando el kernel corregido esté instalado y el servidor reiniciado, puede borrar ese fichero si algún servicio necesita MPTCP.

Conclusión práctica

Es un fallo serio por tres motivos: está en el código que atiende cualquier conexión TCP, no necesita credenciales y ya hay una demostración de explotación completa, aunque no sea pública. Para quien use Debian o Red Hat, la solución es actualizar y reiniciar. Para quien use Ubuntu, la clave estos días es exponer lo mínimo y estar listo para parchear en cuanto salga el kernel.

Si no tiene claro qué servidores tiene su empresa, quién los mantiene o qué puertos tienen abiertos, podemos revisarlo con usted y dejar un procedimiento de actualizaciones para que el próximo fallo no le pille igual.

Fuentes

Información actualizada a 2 de noviembre de 2026. El estado de los parches cambia cada día: consulte siempre la página de su distribución.

Nota editorial: este artículo se ha preparado con ayuda de herramientas de inteligencia artificial y lo ha revisado y publicado Abant Sistemas (LA PEQUEÑA MANZANA SLU), que asume su responsabilidad editorial. Si detectas un error, escríbenos a info@abantsistemas.com.

Servicio relacionado

Servidores, redes e infraestructura

Si esto encaja con lo que tenéis entre manos, aquí explicamos cómo lo abordamos.

Ver el servicio