El equipo de CVE del kernel de Linux publicó CVE-2026-98432, un use-after-free en el código que arma las conexiones TCP entrantes por IPv4, con calificación CVSS 3.1 de 9.8 (crítica): se ataca por red, sin credenciales y sin interacción del usuario. El bug existe desde Linux 4.4 y ya está corregido en todas las ramas estables, pero el parche de tu distribución puede no haber llegado. Al 1 de noviembre, Ubuntu todavía marca su kernel como vulnerable en todas sus versiones y Red Hat sigue sin publicar el arreglo para RHEL 8, 9 y 10. Si administras un servidor Linux que acepta conexiones TCP, o sea casi cualquiera, esto es contigo.
Qué falla exactamente
Según el anuncio del kernel, cuando termina el handshake TCP, la función tcp_v4_syn_recv_sock() le pasa al socket nuevo las opciones IPv4 que traía la petición sin copiarlas. Mientras tanto, otra CPU puede estar procesando un SYN retransmitido de la misma conexión y armando un SYN-ACK con esas mismas opciones. Si la conexión se cierra en ese momento, el kernel libera la memoria con un kfree() normal mientras la otra CPU sigue leyéndola. Leer memoria ya liberada es justo un use-after-free.
El anuncio describe un segundo caso parecido cuando está activa la migración de request sockets (net.ipv4.tcp_migrate_req=1 o un programa BPF de migración). IPv6 no tiene el primer problema porque duplica las opciones; un caso relacionado de IPv6 se arreglará en un parche aparte.
El arreglo, firmado por Eric Dumazet, cambia dos kfree() por kfree_rcu(), que espera a que ningún lector siga usando la memoria antes de liberarla. Está en estas versiones: 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 y 7.3.
Por qué es tan grave
El código vulnerable corre dentro del kernel antes de que cualquier aplicación vea la conexión, así que da igual si tu Nginx o tu SSH están bien configurados. AlmaLinux lo resume así: el disparador es un SYN con opciones IPv4 enviado a un puerto TCP que escucha.
Anthropic, cuyo investigador Xinyang Ge reportó el bug, publicó que Claude escribió un exploit que permite ejecutar comandos como root en servidores Linux con un listener de Multipath TCP (MPTCP), sin credenciales. Según Anthropic, perder la carrera solo hace fallar el handshake sin tumbar el sistema, así que el atacante puede reintentar sin límite. En su prueba de concepto tardó 48 minutos en filtrar un puntero del kernel y cinco minutos más en llegar a ejecutar comandos. Anthropic no ha publicado el exploit.
El detalle de MPTCP importa más de lo que parece. El equipo de seguridad de Go avisó que, desde Go 1.24, los programas en Go abren sus sockets de escucha con MPTCP por defecto en Linux si el kernel lo permite. Y aclaró que el bug no es exclusivo de MPTCP: sistemas sin esos listeners podrían ser vulnerables a ataques parecidos.
Cómo va cada distribución
Lo que cuenta es el kernel de tu distribución, no el número de la versión upstream:
| Distribución | Estado al 1 de noviembre |
|---|---|
| Debian 12 y 13 | Corregido (6.1.190-1 y 6.12.113-1, en el repositorio de seguridad) |
| Ubuntu 16.04 a 26.10 | Vulnerable; arreglo en proceso para 22.04, 24.04, 26.04 y 26.10 |
| RHEL 8, 9 y 10 | Afectados; Red Hat dice que está acelerando los parches |
| AlmaLinux 8, 9 y 10 | Kernels corregidos en el repositorio de pruebas desde el 30 de octubre |
Red Hat calificó el bug como crítico y advierte que cualquier producto que use su kernel, incluido RHEL CoreOS, puede estar afectado. Ubuntu le da prioridad alta.
Qué hacer hoy
Esto sale de los avisos de Red Hat, AlmaLinux y el equipo de Go. No lo probé en un servidor de producción.
- Revisa tu kernel con
uname -ry compáralo con el tracker de tu distribución. En hosts de contenedores y nodos de Kubernetes, revísalo en el host: los contenedores usan el kernel de la máquina. - Actualiza y reinicia en cuanto exista el parche. Sin reinicio, el kernel nuevo no corre.
- Mientras no haya parche, Red Hat y AlmaLinux publicaron una regla de nftables que tira los paquetes TCP por IPv4 que traen opciones IP (
ip hdrlength > 5). El tráfico normal casi nunca las usa. Red Hat aclara que la regla "reduce la exposición… pero no puede prevenirla por completo", y AlmaLinux avisa que el tráfico entre contenedores del mismo host puede saltársela y que no debe usarse en redes que dependan de etiquetas CIPSO. - Busca listeners MPTCP con
ss -Mlnp. Si no usas MPTCP, AlmaLinux sugiere apagarlo connet.mptcp.enabled = 0y reiniciar los servicios que ya lo tenían abierto. Para un programa en Go concreto existeGODEBUG=multipathtcp=0, aunque el propio equipo de Go lo llama una mitigación frágil.
Mi lectura
Un bug de diez años en el camino más transitado del kernel, encontrado y convertido en exploit por un modelo de IA, con un parche de cuatro líneas que tardó semanas en bajar a las distribuciones grandes: esa es la noticia de verdad. El tiempo entre que se publica un parche upstream y que un atacante lo convierte en exploit se está acortando, y el cuello de botella ya no es encontrar el bug, sino tu ventana de reinicio. Si tu servidor corre Ubuntu o RHEL, pon la regla de nftables hoy y deja agendado el reinicio para cuando llegue el kernel.
Fuentes
- Anuncio de CVE-2026-98432 del equipo de CVE del kernel de Linux
- Commit del arreglo e3f33b0 (kernel.org)
- Registro CVE-2026-98432 (cve.org)
- Red Hat, boletín RHSB-2026-016
- Ubuntu, tracker de CVE-2026-98432
- Debian, tracker de seguridad
- AlmaLinux: kernels corregidos en pruebas
- Anthropic: descubrir y explotar vulnerabilidades con Claude
- Equipo de seguridad de Go, vía oss-security
- Análisis de Atlas Security