Publicado el por Félix Molinuevo

CVE-2026-98432: qué hacer si su kernel no tiene parche

Datos al 3 de noviembre de 2026

Qué pasó

CVE-2026-98432 es una falla de tipo use-after-free (uso de memoria ya liberada) en el kernel de Linux, en la parte que procesa el inicio de las conexiones TCP por IPv4. [1][2] La puntuación CVSS es 9,8 sobre 10, asignada por la CNA del kernel de Linux; Red Hat también la califica como crítica. NVD todavía no publicó su propio análisis. [1][3]

Se ataca por red y sin credenciales. Según Akamai y AlmaLinux, el disparador es un paquete SYN con opciones IPv4 seguido de una retransmisión. [4][5] Según Red Hat, requiere una sincronización precisa, y lograr ejecución de código de forma confiable exige control del heap; el efecto más inmediato puede ser una caída del sistema. [3][12]

Anthropic publicó que Claude escribió un exploit que ejecuta comandos como root de forma remota, pero contra servidores con un listener de Multipath TCP (MPTCP) activo. [6] Ese exploit no es público. [4][10] Las fuentes consultadas no informaban campañas de explotación confirmadas al 3 de noviembre [11], y la falla no figura en el catálogo KEV de CISA. [7]

Para conocer otro caso reciente de vulnerabilidades que afectan a servidores y sitios web, consulte nuestro análisis sobre PHP2Shell: qué hacer si su sitio usa PHP.

A quién le importa

A toda empresa con un VPS o servidor Linux con un kernel vulnerable que acepte conexiones TCP por IPv4. Red Hat señala que esos sistemas son los más expuestos. [3] En un VPS o servidor dedicado, el parche lo aplica usted o su administrador. En una plataforma de contenedores administrada por un proveedor, el proveedor debe actualizar el kernel del host. Si administra sus propios contenedores, la responsabilidad sigue siendo suya: los contenedores comparten el kernel del sistema anfitrión.

También puede leer nuestro análisis de Fragnesia (CVE-2026-46300), otra vulnerabilidad relacionada con el kernel de Linux.

Qué distribución tiene parche hoy

El parche ya está en las ramas estables del kernel oficial. [1][8] Estado por distribución al 3/11:

DistribuciónEstadoKernel corregido
Red Hat Enterprise Linux 8Corregido el 1/11 (kernel estándar; el kernel-rt tiene otro aviso, RHSA-2026:93415)4.18.0-553.182.1.el8_10
Red Hat Enterprise Linux 9Corregido el 1/11 en el kernel estándar. La variante kernel-rt continúa marcada como afectada por Red Hat y no tiene una errata de corrección asociada en la ficha del CVE. La página del aviso RHSA-2026:93412 lista paquetes kernel-rt: confirme con Red Hat antes de darla por resuelta5.14.0-687.64.1.el9_8
Red Hat Enterprise Linux 10Corregido el 1/116.12.0-211.72.1.el10_2
AlmaLinux 8, 9 y 10Corregido en los repositorios de producción desde el 2/114.18.0-553.182.1.el8_10, 5.14.0-687.64.1.el9_8 y 6.12.0-211.72.1.el10_2, o posteriores
Debian 12 (bookworm)Corregido6.1.190-1 (con el paquete linux-6.12: 6.12.113-1~deb12u1)
Debian 13 (trixie)Corregido6.12.113-1 o posterior
Ubuntu 22.04Corrección en -proposed (pruebas), no en las actualizaciones normales5.15.0-203.213
Ubuntu 24.04Corrección en -proposed6.8.0-149.149
Ubuntu 26.04Corrección en -proposed7.0.0-43.43
Ubuntu 26.10El blog de Ubuntu lo da por corregido en 7.3.0-10.10; la página del CVE todavía lo marca «vulnerable, trabajo en curso»7.3.0-10.10
Ubuntu 16.04, 18.04 y 20.04Corrección pendientesin versión

Fuentes de la tabla: [2][3][5][8][9][10]. Los datos de Ubuntu están en dos páginas oficiales que hoy no coinciden en 26.10; revíselas el día que aplique el parche.

Que un paquete esté disponible en -proposed no significa que se instale mediante una actualización normal del sistema. Es un canal de pruebas y requiere una instalación explícita. Antes de actualizar, compruebe si el paquete ya pasó al repositorio de actualizaciones correspondiente. [2][10]

Qué hacer

1. Verificar el kernel instalado y el que está corriendo

Compare con la versión corregida de su distribución (tabla anterior), no con la del kernel oficial: las distribuciones aplican el parche sin cambiar la versión principal.

uname -r

Muestra el kernel que está ejecutándose ahora. Para ver los instalados:

dpkg -l 'linux-image*' | grep '^ii'   # Debian y Ubuntu
rpm -q kernel                          # RHEL y AlmaLinux

Un kernel instalado no protege hasta que el servidor arranca con él. Si uname -r muestra una versión anterior a la corregida, falta reiniciar. [3][5]

2. Instalar el parche y reiniciar

Si su distribución ya publicó el kernel corregido, instálelo y reinicie. Programe el reinicio con quien use los servicios.

3. Mientras no haya parche: filtrar paquetes con opciones IPv4

Red Hat, Ubuntu y AlmaLinux publicaron reglas de nftables que descartan los paquetes TCP por IPv4 que traen opciones IP. [2][3][5] Pruébela antes en un entorno no productivo, como indica Red Hat; en AXR no la probamos.

La regla de Red Hat usa el hook input: filtra el tráfico dirigido al propio servidor. [3] Según nuestra lectura, no filtra el tráfico reenviado a otras máquinas. AlmaLinux publica otra regla (tabla ip, cadena prerouting), con comandos propios; use la de su distribución. [5]

Guarde esto en el archivo /etc/cve-2026-98432.nft (texto de Red Hat) [3]. Si lo crea en otra carpeta, cópielo ahí con sudo cp cve-2026-98432.nft /etc/ antes de seguir, porque más abajo se lo referencia por esa ruta:

table inet cve_2026_98432 {
    chain input {
        type filter hook input priority -310; policy accept;
        ip protocol tcp ip hdrlength > 5 counter drop
    }
}

Valide y aplique la regla:

sudo nft --check --file /etc/cve-2026-98432.nft
sudo nft --file /etc/cve-2026-98432.nft
sudo nft list table inet cve_2026_98432

Para que la regla sobreviva a un reinicio, Ubuntu publica estos pasos, que ejecuta una sola vez. Sirven bajo el supuesto de que el firewall se gestiona con /etc/nftables.conf, sin UFW ni firewalld. No son una receta universal. [2]

echo 'include "/etc/cve-2026-98432.nft"' | \
sudo tee -a /etc/nftables.conf
sudo nft -c -f /etc/nftables.conf && sudo systemctl enable nftables.service

Aclaraciones de AXR: ejecute el primer comando una sola vez, porque si no el include se duplica; systemctl enable no inicia el servicio ahora; y si usa UFW, firewalld u otro gestor, revise cómo conviven con /etc/nftables.conf. La regla de AlmaLinux funciona junto con firewalld, pero no sobrevive a un reinicio. [5]

Cuando el kernel esté actualizado y el servidor haya reiniciado con la versión corregida, retire la mitigación. Si configuró la persistencia mediante /etc/nftables.conf, primero elimine la línea del include para evitar que la regla vuelva a cargarse en el próximo arranque. [2]

sudo sed -i '\|^include "/etc/cve-2026-98432.nft"$|d' /etc/nftables.conf

Después, elimine la regla que sigue cargada en el sistema: [3]

sudo nft delete table inet cve_2026_98432

Si instaló la regla sin configurar la persistencia, solo necesita eliminar la tabla. Si la incorporó mediante otro mecanismo, retire también esa configuración.

Límites que conviene conocer antes de aplicarla:

  • Reduce la exposición, pero no la elimina. Red Hat lo dice textualmente. [3]
  • Corta las conexiones que dependen de opciones IPv4, como CIPSO. No afecta las opciones TCP habituales ni el tráfico IPv6. [2]
  • Contenedores: Ubuntu indica que los que tienen red propia necesitan la regla aplicada por separado. AlmaLinux señala que su regla cubre a los contenedores que reciben su tráfico a través del host (el caso por defecto de Podman y Docker), pero que el tráfico entre contenedores del mismo host puede saltearla. [2][5]
  • Filtrar en el borde de la red, antes de que los paquetes lleguen al servidor, puede cubrir más flujos que una regla aplicada únicamente en el host. Pero solo funciona si ese firewall inspecciona efectivamente todos los caminos de entrada relevantes; verifíquelo con quien lo administra. [3]

4. Revisar MPTCP y la migración de conexiones TCP

El exploit demostrado por Anthropic necesita un listener MPTCP. [6] Además, la descripción del CVE menciona una segunda vía, la migración de sockets de conexión, que se activa con net.ipv4.tcp_migrate_req=1 o con un programa BPF de tipo BPF_SK_REUSEPORT_SELECT_OR_MIGRATE. [1] Tres comprobaciones:

sudo sysctl net.mptcp.enabled
sudo ss -lnMp
sudo sysctl net.ipv4.tcp_migrate_req

Los dos comandos sysctl devuelven 1 si el ajuste está activado y 0 si no [5]; tcp_migrate_req viene apagado por defecto. [5] El comando ss -lnMp permite listar los sockets MPTCP en escucha y mostrar el proceso asociado cuando está disponible.

Estas comprobaciones no detectan programas BPF que habiliten la migración por otra vía y no constituyen una auditoría completa de BPF.

Si no usa MPTCP, desactivarlo puede reducir la exposición a la cadena que demostró Anthropic, pero no corrige la vulnerabilidad: según Red Hat, MPTCP no es una condición necesaria, y los sistemas con la configuración por defecto, con MPTCP desactivado, siguen afectados. [3] Ubuntu considera que las actualizaciones son la única mitigación adecuada. [10]

Qué no se sabe todavía

  • Cuándo pasa Ubuntu la corrección al canal normal. Hoy está en pruebas y puede cambiar en cualquier momento. [10]
  • Si el bug se puede explotar sin MPTCP. El exploit publicado por Anthropic lo necesita, pero ni el CVE ni el parche mencionan MPTCP. [1][3]
  • Sobre el modelo. Anthropic dice que, para su investigación en general, usó un modelo interno no publicado, y en la sección de este CVE atribuye el exploit a Claude sin precisar qué modelo. Que fuera «no publicado» en este caso concreto lo da por hecho BleepingComputer. [6][11]

Conclusión

La solución es el kernel corregido y un reinicio; lo demás solo reduce la exposición.

En AXR Global instalamos, configuramos y mantenemos servidores Linux, con soporte para Apache, PHP, MySQL y PostgreSQL. Si necesita revisar sus servidores, puede consultarnos.

Fuentes

  1. NVD, CVE-2026-98432: https://nvd.nist.gov/vuln/detail/CVE-2026-98432
  2. Ubuntu, CVE-2026-98432 (actualizada el 3/11/2026): https://ubuntu.com/security/CVE-2026-98432
  3. Red Hat, RHSB-2026-016: https://access.redhat.com/security/vulnerabilities/RHSB-2026-016
  4. Akamai: https://www.akamai.com/blog/security-research/cve-2026-98432-remote-uaf-linux-kernels-tcp-stack
  5. AlmaLinux: https://almalinux.org/blog/2026-10-30-cve-2026-98432/
  6. Anthropic, Discovering vulnerabilities with Claude (27/10/2026): https://www.anthropic.com/research/discovering-vulnerabilities-with-claude
  7. CISA, catálogo KEV (JSON): https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json
  8. Debian Security Tracker: https://security-tracker.debian.org/tracker/CVE-2026-98432
  9. Red Hat, avisos RHSA-2026:93412 (RHEL 9), 93413 (RHEL 10), 93414 (RHEL 8) y 93415 (RHEL 8 kernel-rt): https://access.redhat.com/errata/RHSA-2026:93412, https://access.redhat.com/errata/RHSA-2026:93413, https://access.redhat.com/errata/RHSA-2026:93414 y https://access.redhat.com/errata/RHSA-2026:93415
  10. Ubuntu, fixes en -proposed: https://ubuntu.com/blog/fixes-available-in-proposed-pocket-for-cve-2026-98432
  11. BleepingComputer: https://www.bleepingcomputer.com/news/security/linux-kernel-exploit-enables-remote-root-attacks-on-mptcp-servers/
  12. Red Hat, ficha del CVE: https://access.redhat.com/security/cve/CVE-2026-98432