¿Qué versión de kernel tienes? El fallo de TCP que en Ubuntu todavía no puedes parchear

·

Los tres avisos de octubre iban de lo que ejecuta tu web: nginx la recibe, PHP o Node la generan.

Este va de lo que hay debajo de todo eso.

CVE-2026-98432 está en el propio núcleo de Linux, en el código que acepta conexiones TCP. Puntúa 9,8 sobre 10 y se ataca desde internet, sin usuario ni contraseña, contra cualquier puerto que esté escuchando.

Y tiene una particularidad incómoda: si usas Ubuntu, a día de hoy no hay parche. El consejo de siempre —actualiza— no se puede seguir.


Qué es el kernel y por qué este fallo es distinto

El kernel es el programa que está por debajo de todos los demás. Reparte la memoria, habla con el disco y la red, y decide qué proceso se ejecuta. Todo lo que corre en tu servidor corre encima de él.

Por eso el alcance no se parece a los anteriores:

Un fallo en…Lo que compromete
Octubrenginx, PHP, Nodetu web o tu aplicación
Ahorael kernella máquina entera, y todo lo que haya en ella

Si en tu servidor conviven la web, la base de datos y las copias de seguridad —que es lo normal en una pyme—, el fallo del kernel las alcanza a las tres a la vez.


El fallo, sin jerga

Cuando alguien abre una conexión TCP con tu servidor, el servidor prepara una estructura temporal mientras se completa el saludo inicial. Si durante ese saludo llega una repetición de la primera petición, dos partes del sistema pueden tocar esa estructura a la vez: una la está usando y otra ya la ha liberado.

Eso es un use-after-free: leer o escribir en una zona de memoria que ya no es tuya. En el mejor caso el servidor se cae. En el peor, el atacante consigue escribir en memoria del kernel.

La corrección oficial cambia kfree() por kfree_rcu() en inet_sock_destruct(), para que la liberación espere a que nadie esté usando esa estructura.

No hace falta tener nada raro instalado. Basta con tener un puerto TCP escuchando: un servidor web, un correo, un SSH.

Un puerto abierto deja de responder a tu servidor y pasa a obedecer a quien envía el paquete, sin usuario ni contraseña y desde internet.
Un puerto abierto deja de responder a tu servidor y pasa a obedecer a quien envía el paquete, sin usuario ni contraseña y desde internet.

Cómo saber si te afecta

uname -r

Eso te da la versión de tu kernel. Compárala:

RamaVersión corregida
5.105.10.272
5.155.15.223
6.16.1.190
6.66.6.159
6.126.12.113

🔴 El fallo arrastra desde la versión 4.4, así que si tu número es más bajo que el de tu rama, te afecta.

⚠️ Pero en Ubuntu el número no se lee así. Ubuntu no usa la numeración de arriba: usa la suya, del tipo 6.8.0-146-generic. Para Ubuntu lo que importa es el número de después del guion.


🔴 Y aquí viene el problema: en Ubuntu todavía no hay parche

Esto es lo que no vas a leer en la mayoría de artículos, porque es incómodo:

SistemaEstado
Debian 12 y 13✅ corregido
Red Hat 8, 9 y 10✅ corregido
Ubuntu 24.04🔴 pendiente — irá en 6.8.0-149
Ubuntu 22.04🔴 pendiente — irá en 5.15.0-203

Ubuntu es la distribución más usada en servidores de empresa. Así que el consejo habitual —«actualiza y listo»— no se puede seguir en la mayoría de los casos. No es dejadez de nadie: el parche está en camino.

👉 Lo que sí puedes hacer es comprobar si ya salió, porque esto cambia de un día para otro:

sudo apt update && apt list --upgradable | grep linux-image

Si aparece una versión superior a la tuya, actualiza y reinicia. Si no, sigue leyendo.


Qué hacer mientras no haya parche

El propio aviso de Ubuntu propone una mitigación: descartar los paquetes TCP que lleguen con opciones IP, que es por donde entra el ataque. Casi ningún tráfico legítimo las usa.

sudo nft add table inet filter
sudo nft add chain inet filter input '{ type filter hook input priority 0; }'
sudo nft add rule inet filter input ip protocol tcp ip hdrlength '>' 5 drop

Para que sobreviva a un reinicio hay que guardarlo en /etc/nftables.conf y dejar el servicio activo:

sudo nft list ruleset | sudo tee /etc/nftables.conf
sudo systemctl enable --now nftables

⚠️ Dos advertencias, y conviene leerlas antes de pegar nada:

  • No elimina el riesgo, lo reduce. Lo dice el propio aviso. Cierra la vía conocida, no el agujero.
  • Puede romper algo. Si alguna aplicación tuya usa opciones IP —es raro, pero pasa en redes con encaminamiento poco habitual—, dejará de funcionar. Hay que probarlo antes en un servidor que no sea el de producción.

🔑 Y una cosa que sí deberías hacer igualmente: mirar qué puertos tienes abiertos a internet. Este fallo se ataca contra cualquier puerto TCP a la escucha, así que cada puerto que no necesites expuesto es superficie que te sobra.

sudo ss -lntp

Lo del exploit escrito por una inteligencia artificial

Este CVE ha salido en la prensa por algo que conviene situar bien.

El 27 de octubre, Anthropic informó de que un modelo interno suyo había construido un exploit funcional: saltarse las protecciones de memoria del kernel y ejecutar una orden como administrador, en unos 53 minutos.

Tres matices que cambian cómo leerlo:

  • No han publicado el código, ni la configuración exacta, ni la versión de kernel que usaron.
  • No consta que se esté usando en ataques reales.
  • Lo hicieron en un laboratorio, contra un servidor preparado.

Dicho eso, lo relevante no es el titular sino lo que implica: el tiempo entre que se publica un fallo y existe una forma de aprovecharlo se está acortando. La ventana para actualizar es más estrecha que hace unos años.

Y un matiz que casi todos los titulares se saltan

Muchos artículos lo llaman «fallo de MPTCP». No lo es. El agujero está en la ruta TCP/IPv4 normal, la que usa todo el mundo. Lo que pasa es que la demostración del exploit se hizo contra un servidor con MPTCP activado, y de ahí salió la confusión.

Que no te tranquilice leer «solo afecta a MPTCP», porque no es verdad.


Qué preguntarle a quien lleve tus servidores

Si esto no lo gestionas tú, copia y pega:

Buenas. Ha salido CVE-2026-98432, un fallo del kernel de Linux que puntúa 9,8 y se explota desde internet. ¿En qué versión de kernel están nuestros servidores, y están por encima de la corregida? Si son Ubuntu y el parche todavía no está disponible, ¿habéis aplicado alguna mitigación mientras tanto?

La segunda pregunta es la que de verdad distingue. Decir «estamos pendientes del parche» es correcto. Decir «estamos pendientes del parche y mientras hemos hecho esto» es otra cosa.

Si te dicen…Significa
La versión concreta y qué han mitigadoHay alguien mirando
«Está todo actualizado»No puede ser, si es Ubuntu: el parche no existe
«Eso no nos afecta» sin explicar por quéNo lo han comprobado

Lo que hacemos en MagicBoxDesk

Comprobar un uname -r son diez segundos. Lo difícil es tener a alguien que sepa que hay que mirarlo, que distinga un aviso que te toca de uno que no, y que sepa qué hacer en el hueco incómodo entre que sale el fallo y llega el parche.

Ese hueco es exactamente donde más empresas se quedan solas.

  • Mantenimiento web — tus versiones al día, sin que tengas que estar pendiente
  • Ciberseguridad — revisión de lo que tienes expuesto a internet, que en este fallo es justo lo que importa
  • SOC gestionado 24/7 — alguien mirando cuando tú no estás

Si solo quieres saber en qué versión estás y si te afecta, escríbenos. Mirarlo es media hora y no cuesta nada.

📍 Alicante y Barcelona · magicboxdesk.com


Fuentes



¿Te ha surgido alguna duda con tu propia infraestructura?

Reserva 30 minutos con un técnico de MagicBoxDesk. Sin compromiso.

Reservar una cita