Fallo crítico en el kernel Linux: qué revisar en tu servidor

Un fallo en el kernel de Linux, el CVE-2026-98432, permite a un atacante sin cuenta corromper la memoria de un servidor mediante conexiones TCP por IPv4 y, en ciertos casos, ejecutar órdenes como administrador. Afecta a servidores que alojan webs. Debian ya tiene parche; Ubuntu y Red Hat, a 30 de octubre de 2026, todavía no.

Lo que se sabe

  • Qué es: un fallo de memoria (un «use-after-free» provocado por una condición de carrera) en el código del kernel que establece las conexiones TCP sobre IPv4, según la descripción del CVE que recogen Ubuntu y Debian. El rastreador de Debian indica que IPv6 no está afectado por la vía principal.
  • Gravedad: Ubuntu y Red Hat le dan 9,8 sobre 10 (CVSS 3.1). Red Hat lo califica de «Critical» para RHEL: dice que un atacante remoto sin autenticar puede corromper la memoria del kernel o tumbar el sistema, y que ejecutar código de forma fiable exige un control preciso de la memoria.
  • La demostración: Anthropic publicó el 27 de octubre que un modelo de investigación interno, no publicado, construyó un exploit que ejecuta órdenes como root sin credenciales ni interacción, contra servidores con un «listener» de Multipath TCP (MPTCP). Según Anthropic, tardó 48 minutos en filtrar un puntero del kernel y unos cinco más en ejecutar la orden. No ha publicado el código.
  • Desde cuándo: según TuxCare, el fallo entró con la versión 4.4 del kernel, en enero de 2016. Ubuntu marca como vulnerables todas sus versiones desde la 16.04.
  • El arreglo: el cambio corrector ya está en el kernel principal y, según Anthropic, se llevó a todas las ramas estables mantenidas. Debian lo distribuye en sus kernels 6.1.190 y 6.12.113.
  • Debian: Debian 12 y Debian 13 tienen kernel corregido (avisos DLA-4841-1, DLA-4850-1 y DSA-6568-1), según su rastreador de seguridad.
  • Ubuntu: su página del CVE, actualizada el 30 de octubre, marca todas las versiones como vulnerables: en la 22.04, 24.04, 26.04 y 26.10 el arreglo está «en curso»; en la 16.04, 18.04 y 20.04 no figura arreglo.
  • Red Hat: su página del CVE marca RHEL 8, 9 y 10 como afectados, todavía sin actualización (RHEL 7 no lo está), y remite a su boletín RHSB-2026-016 para la mitigación. Según TuxCare, Oracle Linux (UEK), SUSE y parte de Amazon Linux 2023 ya tienen parche.
  • Ataques: ninguna de las fuentes consultadas habla de explotación real a 30 de octubre.

Qué cambia y qué no

  • Cambia para quien tiene un servidor propio con Linux (un VPS, un dedicado o una instancia en la nube): necesita un kernel nuevo y un reinicio. Instalar el paquete sin reiniciar deja funcionando el kernel viejo.
  • No es solo MPTCP: la demostración de Anthropic usaba MPTCP, pero Red Hat describe corrupción de memoria o caída con tráfico TCP normal por IPv4. Según TuxCare, RHEL y sus derivadas traen MPTCP desactivado, y los programas hechos en Go 1.24 o posterior lo activan por defecto al escuchar conexiones.
  • No cambia para quien está en hosting compartido o gestionado: el kernel lo controla el proveedor.
  • No toca la web: WordPress, Drupal, PHP y los plugins no tienen nada que ver; es el sistema operativo del servidor.

Cómo saber si te afecta

  1. Averigua de quién es el servidor. Si tu web está en un VPS, un servidor dedicado o una máquina en la nube, el kernel es tuyo. Si está en hosting compartido, ve al paso 5.
  2. Mira la versión del kernel con `uname -r` en una terminal del servidor y apunta tu distribución y su versión.
  3. Consulta la página del CVE de tu distribución (enlaces abajo). Debian ya tiene paquete; Ubuntu y RHEL, todavía no a 30 de octubre: vuelve a mirar en los próximos días.
  4. Cuando salga el paquete, instálalo y reinicia en una franja de poco tráfico. Mientras tanto, sigue la mitigación oficial de tu distribución (en RHEL, el boletín RHSB-2026-016). Con `sysctl net.mptcp.enabled` sabes si MPTCP está activo (1) o no (0).
  5. En hosting compartido o gestionado, pregunta a tu proveedor: «¿Vuestros servidores ya corren un kernel con el arreglo de CVE-2026-98432? Si no, ¿qué mitigación habéis aplicado?».
  6. No olvides lo demás: el servidor de pruebas o de staging también cuenta. Los contenedores (Docker) usan el kernel de la máquina que los aloja: lo que hay que actualizar es esa máquina.

Relacionado: Fallo en HTTP/3 puede tumbar servidores: qué revisar

Fuentes

Actualizaciones: cuando Ubuntu o Red Hat publiquen el kernel corregido, o si se confirman ataques, se añadirá aquí con su enlace.