El 2 de noviembre de 2026, Fortinet PSIRT publicó el aviso FG-IR-26-188 sobre CVE-2026-98432, un use-after-free con CVSS 9,8 en la pila TCP IPv4 del kernel de Linux. El aviso llega tarde: el equipo de CVE del kernel publicó el CVE el 15 de octubre, la corrección upstream se incorporó el 5 de octubre y los kernels corregidos de Red Hat se distribuyeron desde el 1 de noviembre. Planifica a partir de la cronología del kernel, no de la fecha de Fortinet.

El fallo acompaña al kernel allá donde se ejecute: hosts de hipervisor, nodos de contenedores, máquinas virtuales invitadas. Si operas tus propios hosts, tienes que decidir un orden. A continuación te explicamos cómo lo razonamos, qué dicen las pruebas sobre su explotabilidad y dónde encaja un filtro de opciones IP mientras se despliegan los kernels.

El fallo está en la ruta IPv4 normal

Cuando una solicitud de conexión lleva opciones IPv4, el kernel podía liberar esas opciones mientras otra CPU seguía leyéndolas para responder a un SYN retransmitido. La corrección cambia a kfree_rcu() en inet_sock_destruct() y tcp_v4_reqsk_destructor(). El fallo está presente desde Linux 4.4. Otras fuentes señalan las opciones Record Route y Timestamp como desencadenante; el texto de Fortinet no lo hace.

Según la página de Fortinet, IPv6 no se ve afectado por este primer problema, pero existe un problema de migración similar con las opciones establecidas mediante CALIPSO, con un parche independiente por llegar. MPTCP no es necesario: el fallo está en la ruta TCP normal, y el exploit de Anthropic usaba un listener MPTCP. Desactivarlo con net.mptcp.enabled=0 (o GODEBUG=multipathtcp=0 en Go 1.24 o posterior) restringe las condiciones en las que se puede explotar, tal como lo describe AWS, pero no corrige nada.

Cuánta preocupación está justificada

Las puntuaciones no coinciden. La CNA del kernel le asigna 9,8; una fuente indica que Red Hat lo puntúa con 5,9 porque la explotación depende de ganar una condición de carrera, mientras que otra afirma que Red Hat lo calificó como crítico, así que lee el boletín de la propia Red Hat en lugar de fiarte de cualquiera de los dos resúmenes. Fortinet marca Known Exploited como «No», y ThreatDefence no notificó explotación activa ni inclusión en el catálogo KEV de CISA a fecha de 9 de noviembre.

Circula código de prueba de concepto público desde el 29 de octubre. Cubre la condición de carrera y una fuga de punteros del kernel, no la ejecución de código, y Marcus Hutchins informa de escaneos de MPTCP desde el 2 de noviembre. CloudLinux no logró reproducir el exploit de root remoto. Es, por tanto, un fallo para parchear en este ciclo y no un motivo para reiniciarlo todo esta noche, pero los hosts expuestos no deberían esperar a una ventana mensual.

Una puntuación CVSS te dice lo grave que es el fallo. Tu orden de parcheo depende de dónde es alcanzable el kernel y de qué hay a su lado.

Estrategia de parcheo del kernel: primero la exposición, después el radio de impacto

No hemos encontrado ninguna guía de fabricantes sobre cómo ordenar hosts de hipervisor, nodos e invitados, así que este es nuestro propio razonamiento, construido sobre lo que sí dicen las fuentes.

  1. Hosts expuestos a internet que terminan TCP. Cualquiera puede enviarles un SYN con opciones, así que van los primeros. Dentro de ese grupo, ThreatDefence sitúa a continuación los listeners MPTCP y los de Go 1.24 o posterior; el exploit de Anthropic usaba un listener MPTCP.
  2. Nodos de contenedores compartidos o multiinquilino. Los contenedores comparten el kernel del host, así que la corrección es actualizar el kernel del nodo de Kubernetes; reconstruir las imágenes no cambia nada. El boletín de GKE de Google, tal como lo recoge ThreatDefence, dice que un proceso de contenedor sin privilegios puede desencadenar el fallo de forma local. Ningún otro fabricante lo ha dicho, pero si es cierto, un nodo compartido se sitúa al nivel de los hosts expuestos a internet.
  3. Hosts de hipervisor. El fallo está en la pila TCP del propio host, así que importa para las interfaces de gestión del host y para cualquier servicio que exponga. Los invitados KVM ejecutan sus propios kernels y el tráfico de los invitados no termina en el kernel del host, de modo que parchear un host no parchea a sus invitados. Lo que determina la posición de este nivel es el coste: reiniciar un host que aloja muchas cargas de trabajo es el reinicio más caro que programarás (razonamiento nuestro, no de un fabricante), así que reserva su ventana cuanto antes en lugar de descubrir la restricción el mismo día.
  4. Hosts tras un paso directo de capa 4 y, después, hosts internos. Según el orden de ThreatDefence, los hosts tras un paso directo van por encima de las máquinas puramente internas; nuestro razonamiento es que un paso directo de capa 4 no reescribe el SYN del cliente, así que las opciones llegan al host.

La exposición marca el orden; el radio de impacto desempata. Entre dos hosts igual de expuestos, parchea primero el que aloja más cargas de trabajo.

En instancias no gestionadas, el kernel del invitado es tuyo

Nuestras instancias cloud funcionan sobre KVM, y el kernel del host que hay debajo lo parcheamos nosotros. VPS, VDS y MEM son no gestionadas, así que el kernel del invitado es responsabilidad tuya: parchear nuestros hosts no parchea tu invitado. Lo mismo ocurre con los servidores bare metal con un sistema operativo que hayas instalado tú. En un servidor bare metal gestionado, parcheamos nosotros el sistema operativo.

En las instancias MNG, qué software cubre la gestión es algo que conviene confirmar con nosotros para tu carga de trabajo; no des por hecho que el kernel esté incluido. En cada invitado no gestionado, comprueba uname -r frente a las versiones corregidas que figuran más abajo y programa tú mismo el reinicio.

Control provisional: un filtro de opciones IP con nftables

Red Hat y Canonical publican la misma medida provisional, la regla ip protocol tcp ip hdrlength > 5 counter drop, que descarta los paquetes TCP cuya cabecera IP es más larga que el mínimo de 5 palabras, es decir, los que llevan opciones. Los fabricantes publican únicamente esa regla. La tabla y la cadena que la envuelven más abajo son de cosecha propia, así que pruébalas antes de usarlas.

table ip ipopts {
  chain input {
    type filter hook input priority 0; policy accept;
    ip protocol tcp ip hdrlength > 5 counter drop
  }
}

Cárgalo primero sin drop, para que el contador te muestre si algo de lo que ejecutas depende de las opciones IP. Red Hat advierte de que puede interrumpir cargas de trabajo que dependan de ellas, y RFF advierte de que no debe usarse en redes etiquetadas con CIPSO. Red Hat, Canonical y AWS lo describen como una forma de reducir la exposición, no de impedir la explotación. Te da tiempo; no es un parche.

La misma condición de filtrado en el borde de la red, en un firewall o un balanceador de carga en la nube que descarte los paquetes IPv4 con opciones, protegería a todos los hosts que haya detrás. Esto solo lo describen los fabricantes. Nosotros operamos la red y el tránsito en los cuatro centros, así que la ubicación del filtro la decidimos nosotros, y lo probaríamos en nuestro propio borde antes de fiarnos de él. Lo difícil es la cobertura: AMS1 tiene seis enlaces ascendentes de operador y MUN1 tiene ocho, y si hay un filtro por enlace en lugar de en los routers, una cobertura parcial equivale a no tener cobertura (es razonamiento nuestro, no de un fabricante).

Si usas productos de Fortinet, Fortinet recoge un parche virtual, Linux.Kernel.tcp_v4_syn_recv_sock.Use.After.Free., en la actualización FMWP db 26.113, y la revisión del 7 de noviembre añadió información del paquete IPS. Fortinet también incluye unos 55 de sus productos como todavía en análisis, entre ellos FortiOS y FortiGate Cloud.

Kernels corregidos y lo que sigue abierto

  • Upstream: 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 y 7.3.
  • RHEL 9.8: 5.14.0-687.64.1.el9_8. RHEL 10.2: 6.12.0-211.72.1.el10_2.
  • Ubuntu 24.04: 6.8.0-149.149. Según ThreatDefence, las correcciones para 22.04, 24.04 y 26.04 llegaron a -updates del 5 al 6 de noviembre, pero no había ningún Ubuntu Security Notice ni nada en -security a fecha de 9 de noviembre. Un host que siga solo -security todavía no lo verá.
  • Proxmox VE 9: proxmox-kernel-7.0.14-25-pve o posterior (PSA-2026-00080-1).
  • El boletín 2026-160-AWS de AWS cubre Amazon Linux, EKS y Bottlerocket. Las imágenes de nodo GKE Ubuntu aún no estaban corregidas.

ThreatDefence no encontró ningún kpatch de Red Hat ni ningún aviso de Livepatch de Ubuntu. Si reiniciar resulta caro, existen TuxCare KernelCare, los parches en caliente de SUSE y Oracle Ksplice (solo UEK). Vuelve a comprobar el estado en tu distribución antes de actuar sobre cualquiera de estos puntos: el estado de las correcciones cambia con frecuencia.

Fuentes