CVE-2026-98432: vulnerabilidad TCP en el kernel Linux — qué es y qué hacer en tu VPS o servidor dedicado

A 29 de octubre de 2026, la vulnerabilidad CVE-2026-98432 del kernel Linux tiene parche en las ramas estables oficiales y en Debian, pero Ubuntu, Red Hat, AlmaLinux, Rocky y SUSE 15 todavía no han publicado un kernel corregido. En el momento de publicar no consta ningún exploit público. Si tienes un VPS o un servidor dedicado Linux con Fusiora, el kernel lo gestionas tú: en este artículo te contamos qué ha pasado y qué pasos seguir.

Qué ha pasado, en lenguaje llano

Cuando alguien abre una conexión TCP con tu servidor, el kernel guarda temporalmente cierta información del primer paquete (el SYN). Si ese paquete trae opciones IPv4 (campos opcionales de la cabecera IP, como Record Route o Timestamp, que el tráfico normal casi nunca usa), el kernel puede liberar esa memoria mientras otra parte del sistema todavía la está usando. Es lo que se llama un use-after-free.

En la práctica, lo más probable es que el servidor se cuelgue y se reinicie (denegación de servicio). Las fuentes oficiales no coinciden en la gravedad: el registro del CVE habla también de posible filtración al atacante de contenido de la memoria del kernel y de corrupción de memoria, mientras que Red Hat indica que lo más probable es un cuelgue y que no se ha demostrado impacto en la confidencialidad ni en la integridad.

Detalle técnico breve

• Corrección: commit e3f33b0a1d89 «ipv4: free inet_opt and ireq_opt after an RCU grace period» (Eric Dumazet, 1 de octubre de 2026), incluido en Linux 7.3. Cambia dos kfree() por kfree_rcu() en net/ipv4/af_inet.c y net/ipv4/tcp_ipv4.c.
• Causa: tcp_v4_syn_recv_sock() pasa al socket hijo las opciones IP de la petición sin copiarlas. Si llega a la vez un SYN retransmitido, otra CPU puede estar enviando un SYN-ACK con esas opciones mientras el hijo se destruye y las libera.
• Segunda variante: solo con la migración de peticiones TCP activada (net.ipv4.tcp_migrate_req=1, que por defecto vale 0, o con un programa BPF de reuseport que migre peticiones).
• Vector: remoto y sin autenticación, durante el handshake, antes de que la aplicación intervenga. Hace falta un servicio TCP escuchando en IPv4, que el SYN lleve opciones IP y ganar una carrera de tiempos. El CNA la considera de complejidad baja; Red Hat y SUSE, alta.
• IPv6: no está afectado por el fallo principal. No hace falta desactivar IPv6.

¿A quién afecta?

• VPS Linux: cada VPS arranca su propio kernel, que instalas y actualizas tú desde el sistema operativo. Si tu VPS usa un kernel vulnerable, tienes que actualizarlo y reiniciar.
• Servidores dedicados Linux: igual. Tienes acceso root completo y el kernel es responsabilidad tuya.
• Contenedores (Docker, LXC, Podman) dentro de tu servidor: comparten el kernel del anfitrión, así que se protegen actualizando el kernel de ese servidor.
• No afectados: Windows Server y FreeBSD, porque no usan el kernel Linux.

Estado de los parches a 29 de octubre de 2026

Kernels oficiales (kernel.org). Estas versiones, o cualquier posterior de la misma rama, ya incluyen la corrección:

El registro del CVE no incluye ninguna rama corregida 4.x ni 5.4 (ramas sin soporte oficial).

Por distribución. Ojo: las distribuciones numeran sus kernels a su manera, así que lo que cuenta es el paquete corregido de cada una:

En las distribuciones con kernels recientes de las ramas oficiales (por ejemplo Fedora, Arch o Alpine), compara tu versión con la tabla de kernel.org. Si usas Debian 10 u 11 u otro sistema sin soporte, no cuentes con recibir un parche: planifica migrar a una versión con soporte (en un VPS, desde el panel, Manage → Rebuild; ojo, reinstalar borra todos los datos; en un dedicado, abre un ticket). CentOS 7 usa el kernel de RHEL 7, que según Red Hat no está afectado por este CVE, pero ya no recibe actualizaciones de seguridad: conviene migrar igualmente.

Pasos para el cliente

Conéctate por SSH (guía) y ejecuta los comandos como root o con sudo.

1. Comprueba qué kernel estás usando

uname -r

En Debian, el número exacto del paquete aparece al final de:

uname -v

Por ejemplo, «Debian 6.12.113-1» o superior en Debian 13 indica que ya tienes la versión corregida. En Ubuntu, RHEL y derivadas, el número de uname -r es el de la distribución: compáralo con su aviso, no con la tabla de kernel.org.

2. Haz una copia de seguridad antes de tocar nada

Si tu plan incluye snapshots, crea uno antes de actualizar. Si no, copia fuera del servidor lo que no puedas perder. Actualizar el kernel es una operación rutinaria, pero el reinicio es el momento en el que un problema previo puede salir a la luz.

3. Actualiza el sistema

Debian y Ubuntu:

apt update && apt full-upgrade

En Debian 12, si usas el kernel 6.12 del paquete linux-6.12 (DLA-4850-1), full-upgrade también lo actualiza. Para comprobar los paquetes de kernel instalados:

dpkg -l 'linux-image*'

AlmaLinux, Rocky, RHEL, Fedora, Oracle y CloudLinux:

dnf upgrade --refresh

rpm -q kernel

SUSE y openSUSE:

zypper refresh && zypper patch

Arch:

pacman -Syu

Alpine:

apk update && apk upgrade

En Ubuntu, RHEL, AlmaLinux y Rocky, a 29 de octubre todavía no hay kernel corregido; en Oracle Linux (kernel UEK) y CloudLinux, consulta el aviso de tu proveedor. Aun así, merece la pena aplicar las actualizaciones pendientes, y conviene repetir este paso en cuanto tu distribución publique el aviso (ver el paso 8); mientras tanto, aplica la mitigación del paso 5.

4. Reinicia y comprueba la versión nueva

El kernel nuevo no se usa hasta que reinicias:

reboot

Cuando vuelva a responder, repite uname -r (y uname -v en Debian) y compárala con el paquete corregido de tu distribución (tabla «Por distribución»), o con la de kernel.org si usas un kernel oficial. Si el servidor no responde por SSH después de reiniciar:

• VPS: entra en el panel vps.fusiora.com y abre la consola VNC (pestaña Options → Browser VNC; si no ves el botón, pulsa antes Enable VNC).
• Dedicado: usa la consola remota IPMI/KVM.
• En el menú de GRUB (en Debian y Ubuntu, dentro de «Advanced options»; si no aparece, mantén pulsada Shift o pulsa Esc al arrancar) puedes elegir el kernel anterior mientras lo investigas.

5. Si tu distribución aún no tiene parche: mitigación temporal

El fallo solo se dispara con SYN TCP IPv4 que llevan opciones IP, algo muy poco habitual en tráfico legítimo. Puedes descartar esos paquetes con nftables. La regla deja pasar los SYN normales y no afecta a IPv6 ni a otros protocolos. Si tu servidor reenvía tráfico (por ejemplo, como router o pasarela VPN), también filtra esos SYN en tránsito. No sustituye al parche.

Si no tienes el comando nft, instálalo con apt install nftables o dnf install nftables. La regla va en una tabla propia, que convive con ufw, firewalld y Docker:

nft add table inet cve_2026_98432

nft add chain inet cve_2026_98432 pre '{ type filter hook prerouting priority -300; policy accept; }'

nft add rule inet cve_2026_98432 pre 'ip hdrlength > 5 tcp flags & (syn | ack) == syn counter drop'

Para comprobarla (el contador indica cuántos paquetes ha descartado):

nft list table inet cve_2026_98432

Para quitarla:

nft delete table inet cve_2026_98432

Así la regla no sobrevive a un reinicio. No la añadas a /etc/nftables.conf ni actives nftables.service para esto: según la distribución, esa configuración vacía todas las reglas del sistema, incluidas las de Docker o ufw. Si necesitas mantenerla tras reiniciar, guárdala en un fichero propio, /etc/cve-2026-98432.nft:

table inet cve_2026_98432 {
  chain pre {
    type filter hook prerouting priority -300; policy accept;
    ip hdrlength > 5 tcp flags & (syn | ack) == syn counter drop
  }
}

Y cárgala con un servicio propio, /etc/systemd/system/cve-2026-98432.service:

[Unit]
Description=Mitigacion CVE-2026-98432

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/sbin/nft -f /etc/cve-2026-98432.nft
ExecStop=/usr/sbin/nft delete table inet cve_2026_98432

[Install]
WantedBy=multi-user.target

Primero quita la regla manual, si la habías añadido (nft delete table inet cve_2026_98432), para que no quede duplicada. Después:

systemctl daemon-reload && systemctl enable --now cve-2026-98432.service

Cuando tengas el kernel corregido, desactívala con systemctl disable --now cve-2026-98432.service.

En sistemas antiguos sin nftables, el equivalente con iptables es:

iptables -t raw -I PREROUTING -p tcp --syn -m u32 ! --u32 "0>>22&0x3C=20" -j DROP

Igual que la regla nft añadida a mano, esta no sobrevive a un reinicio.

Comprueba también que la variante de migración está desactivada (debe devolver 0, el valor por defecto):

sysctl net.ipv4.tcp_migrate_req

Si responde que la clave no existe, tu kernel no tiene esa función y esta variante no aplica.

No filtres todos los paquetes con opciones IP: IGMP las usa y romperías la multidifusión. La regla de arriba se limita a los SYN TCP a propósito.

6. Livepatch: solo donde exista

A 29 de octubre de 2026 no hemos encontrado ningún parche en caliente (livepatch) para este CVE de Canonical, Red Hat ni SUSE. SUSE sí ha publicado el kernel corregido para la versión 16.0 (6.12.0-160000.40.1), que requiere reiniciar. Sin livepatch, la solución pasa por actualizar el kernel y reiniciar.

7. Revisa qué expones a Internet

El fallo necesita un servicio TCP escuchando en IPv4. Es buen momento para cerrar en el cortafuegos (ufw o firewalld) los puertos que no necesitas y limitar a tus IPs los de administración. La configuración básica del cortafuegos está en la guía Configura tu primer VPS.

8. Vigila los avisos y pide ayuda si la necesitas

Sigue la página del CVE de tu distribución (enlaces abajo) y, cuando aparezca el kernel corregido, repite los pasos 3 y 4. Si tienes dudas o algo no arranca después de actualizar, abre un ticket indicando tu servicio y la salida de uname -r.

Preguntas frecuentes

¿Fusiora actualiza el kernel de mi VPS o de mi dedicado?

No, salvo que tengas contratado un servicio gestionado; en ese caso, consulta con soporte. Con un VPS o dedicado estándar tienes acceso root completo y el sistema operativo lo gestionas tú, kernel incluido. Si quieres ayuda con los pasos, abre un ticket.

¿Basta con actualizar los paquetes?

No. Hasta que reinicias sigues usando el kernel anterior. Comprueba con uname -r que estás en la versión nueva.

¿Tengo que desactivar IPv6?

No. IPv6 no está afectado por el fallo principal.

¿La regla de nftables puede romper algo?

Solo descarta SYN TCP IPv4 con opciones IP, que son muy poco habituales en tráfico legítimo. No toca IPv6 ni otros protocolos, y se quita con un comando.

¿Mi Windows Server está afectado?

No. Es una vulnerabilidad del kernel Linux.

¿Se está explotando ya?

En el momento de publicar no consta ningún exploit público y el CVE no figura en el catálogo KEV de CISA. Actualizaremos este artículo si eso cambia.

---

Fuentes

• CVE.org: registro oficial del CNA de Linux, publicado el 2026-10-15 y actualizado el 2026-10-24
• NVD: ficha del CVE con la puntuación del CNA (consultado el 2026-10-29)
• Ubuntu: estado por versión, prioridad High (actualizado el 2026-10-28)
• Debian Security Tracker: paquetes corregidos, DSA-6568-1, DLA-4841-1 y DLA-4850-1 (consultado el 2026-10-29)
• Red Hat: valoración Moderate y estado «Fix deferred» (consultado el 2026-10-29)
• SUSE: estado por producto (consultado el 2026-10-29)
• Commit de la corrección en Linux: «ipv4: free inet_opt and ireq_opt after an RCU grace period» (2026-10-01)
• kernel.org: versiones estables actuales (consultado el 2026-10-29)
• CISA KEV: catálogo de vulnerabilidades explotadas, sin este CVE (consultado el 2026-10-29)