CVE-2026-98432: falla crítica en el kernel de Linux y cómo aplicar un parche virtual

El 15 de octubre de 2026 se publicó el CVE-2026-98432, una falla en el kernel de Linux que se dispara durante el saludo inicial de una conexión TCP por IPv4. No requiere usuario, contraseña ni que nadie haga clic: basta con que el servidor tenga un puerto TCP abierto. La autoridad que asignó el CVE, el propio equipo del kernel, le dio una calificación de 9.8 sobre 10 (crítica). A la fecha de este artículo, NVD todavía no publica su propio análisis.

La buena noticia: el ataque depende de un detalle del tráfico que casi nadie usa de forma legítima, las opciones IP. Eso permite cerrarle la puerta hoy, con un parche virtual en el firewall o en el propio servidor, mientras llega el kernel corregido de tu distribución.

¿Qué es exactamente la falla?

Es un use-after-free: el kernel libera un bloque de memoria y después lo sigue usando. Pasa así:

1. El atacante abre una conexión con un paquete SYN que trae opciones IP, por ejemplo Record Route o Timestamp. El kernel las guarda junto con la conexión a medio abrir.
2. Mientras el kernel termina de crear la conexión, el atacante retransmite el SYN. Ese SYN repetido hace que el servidor arme otra respuesta SYN-ACK con las mismas opciones.
3. Si la conexión se cierra y se libera justo en ese momento, el kernel construye el SYN-ACK leyendo memoria que ya no le pertenece.

Según la descripción oficial, el resultado puede ser cualquiera de tres cosas: que el kernel se caiga (el servidor se reinicia o se congela), que el SYN-ACK salga con pedazos de memoria del kernel hacia el atacante, o escrituras fuera de límites que en teoría abren la puerta a tomar el control. Es una carrera de tiempos, así que no se gana a la primera, pero el atacante puede repetirla cuantas veces quiera.

IPv6 no es vulnerable al caso principal.

¿A quién le afecta?

A cualquier equipo con kernel de Linux desde la versión 4.4 que acepte conexiones TCP por IPv4. En la práctica:

• Servidores web, de correo, de bases de datos o de aplicaciones en Linux, sobre todo los publicados a internet.
• Hipervisores y equipos basados en Linux: nodos de virtualización, NAS, balanceadores y muchos appliances de red. En estos, el parche lo publica el fabricante, no tu distribución.
• Contenedores: comparten el kernel del host, así que el que se parcha es el host.

Lo que más importa es la exposición: un servidor con un puerto abierto a internet es el primer candidato. Uno que solo atiende tráfico interno depende de que nadie dentro de la red esté comprometido.

¿Ya hay parche?

En el kernel oficial, sí. La corrección entró en las versiones 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56 y 7.2.10, y en la rama 7.3. En las distribuciones el avance es desigual. Así estaba el 29 de octubre de 2026:

Para saber qué kernel corre un servidor, usa uname -r. Recuerda que instalar el paquete nuevo no basta: el kernel corregido entra en funciones hasta que reinicias, salvo que uses parcheo en vivo.

Parcheo virtual: cerrar la puerta mientras llega el parche

Un parche virtual no corrige la falla; impide que el tráfico que la explota llegue al equipo vulnerable. Aquí es especialmente útil porque el ataque necesita paquetes TCP con opciones IP, y el tráfico legítimo de internet prácticamente nunca las usa. Muchos ruteadores ya las descartan. Bloquearlas tiene muy bajo riesgo de romper algo.

En el FortiGate: firma IPS personalizada

Fortinet permite escribir firmas IPS propias, y su sintaxis incluye la palabra clave --ip_option para detectar opciones IP. Una firma que bloquea cualquier TCP por IPv4 con opciones se ve así:

config ips custom
    edit "CVE-2026-98432.TCP.IPv4.Options"
        set signature "F-SBID( --name \"CVE-2026-98432.TCP.IPv4.Options\"; --protocol tcp; --ip_option any; )"
        set severity critical
        set action block
        set log enable
        set log-packet enable
        set status enable
    next
end

Después agrégala al sensor IPS que usan tus políticas de entrada, con la acción Block: Security Profiles → Intrusion Prevention, abre el sensor y en Create New → Signatures busca el nombre. Tres cuidados:

• Valida la sintaxis en tu versión. Si tu FortiOS rechaza any, crea dos firmas, una con --ip_option rr; y otra con --ip_option ts;, que son las opciones del ataque.
• Solo protege lo que cruza una política con IPS. Revisa que todas las políticas de entrada hacia servidores publicados (las de VIP) tengan ese sensor. Si tienes IPS entre VLANs, la firma también protege los servidores internos.
• Confirma que bloquea. Los eventos aparecen en Log & Report → Security Events → Intrusion Prevention, o desde la CLI si no tienes FortiAnalyzer, como explicamos en leer los logs del FortiGate desde el CLI.

En el servidor Linux: una regla de nftables

Si no hay un firewall con IPS delante, o como segunda capa, el propio servidor puede descartar esos paquetes. Un encabezado IPv4 sin opciones mide 5 palabras de 32 bits; cualquier valor mayor significa que trae opciones. Esta tabla aparte descarta el TCP por IPv4 con opciones antes de que llegue a la pila TCP:

nft add table inet cve98432
nft add chain inet cve98432 input '{ type filter hook input priority -150; policy accept; }'
nft add rule inet cve98432 input ip hdrlength != 5 meta l4proto tcp counter drop

Se ejecuta como root y no toca tus otras reglas. Pruébala primero en un equipo que no sea de producción. Para quitarla cuando instales el kernel corregido: nft delete table inet cve98432. Recuerda que una regla agregada así se pierde al reiniciar; si la necesitas hasta entonces, pásala a la configuración persistente de nftables.

¿Cómo saber si te están buscando?

Con tcpdump puedes ver si llegan SYN con opciones IP a un servidor:

tcpdump -ni any 'ip[0] & 0x0f > 5 and tcp[tcpflags] & tcp-syn != 0'

En un servidor normal esto debería quedarse en silencio. Si aparecen paquetes, sobre todo de muchas direcciones distintas, alguien está probando. En el FortiGate, la firma de arriba deja el mismo rastro en el registro de IPS.

Orden de trabajo recomendado

1. Inventario: qué equipos con Linux aceptan conexiones TCP por IPv4 desde internet. Incluye hipervisores, NAS y appliances.
2. Parche virtual hoy: la firma en el firewall perimetral y, donde no haya firewall con IPS, la regla de nftables.
3. Prueba: confirma en el registro que el bloqueo funciona y que el tráfico normal sigue pasando.
4. Parche real: instala el kernel corregido en cuanto lo publique tu distribución o tu fabricante, y reinicia en una ventana. Si tienes anillos de despliegue, este es buen candidato para acelerarlos, sin saltarte la prueba; lo explicamos en parchar rápido no es parchar a ciegas.
5. Retiro: cuando todos los equipos tengan el kernel nuevo, desactiva la firma y la regla. Un parche virtual olvidado se vuelve una regla que nadie entiende dentro de un año.

Para los equipos que no van a recibir parche, como un appliance fuera de soporte, el parche virtual deja de ser temporal y pasa a ser un control compensatorio permanente. Es el mismo razonamiento que usamos para proteger lo que no se puede parchear.

Si necesitas apoyo para inventariar tu exposición, aplicar el parche virtual o coordinar la actualización de kernels, nuestro equipo de ciberseguridad puede ayudarte.

Fuentes: registro CVE-2026-98432 en cve.org y NVD (publicado el 15 de octubre de 2026, actualizado el 24 de octubre), Debian Security Tracker, Ubuntu CVE Tracker y la guía de firmas personalizadas de Fortinet. Estado de las distribuciones consultado el 29 de octubre de 2026.