CVE-2026-98432: el fallo 9.8 de Linux que Claude explotó

El fallo que se dispara antes de que tu aplicación vea la conexión

El kernel de Linux arrastra desde la versión 4.4 un use-after-free en el manejo del handshake IPv4 TCP que el propio equipo CNA del kernel puntuó CVSS 3.1 9.8, crítico. Lo que importa para un founder: la ruta vulnerable corre cuando el servidor acepta una conexión TCP, antes de que Nginx, PostgreSQL, SSH o tu API vean un solo byte. El atacante no necesita credenciales ni interacción del usuario.

El fallo está registrado como CVE-2026-98432, con el título ipv4: free inetopt and ireqopt after an RCU grace period. El arreglo upstream es un cambio de cuatro líneas de Eric Dumazet que reemplaza dos llamadas kfree() por kfree_rcu(), para que el kernel espere a que todos los lectores terminen antes de liberar la memoria. El problema es que casi nadie corre el kernel upstream: los servidores corren el kernel de su distribución, y ahí el parche llega con otro número de versión y otro calendario.

¿Cómo funciona el use-after-free del handshake TCP?

Cuando un servidor Linux acepta una conexión, el kernel guarda el handshake a medio completar en un request socket liviano y crea el socket definitivo cuando el handshake termina. Si el header IPv4 del peer traía opciones, el kernel las conserva para repetirlas en sus respuestas.

Leíste lo que hace la IA. ¿Y en tu negocio?

Un agente de IA puede quedarse con parte de tu día: ordenar lo pendiente y pedirte el OK antes de actuar. El Kit «tu mano derecha con IA» trae un video de 11 minutos y una ficha para dejar al tuyo trabajando. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

El bug: el kernel le pasaba esas opciones guardadas al nuevo socket sin copiarlas, y las liberaba de inmediato cuando la conexión se cerraba, mientras otra CPU todavía podía estar leyéndolas para construir una respuesta SYN-ACK. Leer memoria del kernel ya liberada es, literalmente, un use-after-free.

Las notas de puntuación del CNA describen tres resultados posibles: filtrar contenido del heap del kernel al peer remoto, corromper memoria del kernel o tumbar la máquina. Red Hat lo describe como principalmente un crash del sistema que lleva a una denegación de servicio (DoS) o potencial corrupción de memoria. Las conexiones IPv6 no están afectadas por esta carrera, porque ahí el kernel sí copia las opciones.

Por qué Anthropic es el nombre que cambia esta historia

El bug lo reportó Xinyang Ge, de Anthropic. La empresa dice que su modelo Claude escribió un exploit funcional que ejecuta comandos como root en servidores Linux con un listener de multipath TCP, sin credenciales. El exploit no se publicó.

El ataque tiene dos etapas. Primero gana la carrera para que el kernel devuelva bytes extra y filtra un puntero del kernel, lo que rompe KASLR, la aleatorización de direcciones de memoria del kernel. Después usa el mismo bug para sobrescribir un puntero de callback con la dirección de un payload que ya había colocado en memoria del kernel; cuando el kernel llama a ese puntero, ejecuta un comando arbitrario como root.

En la prueba de Anthropic, filtrar el puntero tardó 48 minutos y llegar a la ejecución de comandos cinco minutos más. Una carrera perdida solo falla ese intento de conexión sin tumbar el sistema, así que un atacante puede reintentar indefinidamente. Anthropic sigue una política de divulgación coordinada de 90 días para parchear, más 45 días antes de hablar de detalles.

Vale la pena leer ese dato en contexto. Según Help Net Security, Anthropic apuntó un modelo a 281 proyectos open source y recolectó 23.019 vulnerabilidades candidatas, de las cuales solo 1.900 fueron revisadas por alguien fuera de la empresa. Y en una encuesta de Echo a más de 80 responsables de seguridad, el 37% dijo que detectar más vulnerabilidades de las que puede remediar es su mayor barrera. Ese es el mundo al que entran los equipos pequeños.

¿Qué distribuciones ya tienen el parche y cuáles no?

El arreglo upstream llegó en 7.2.10 y 6.18.56 el 11 de octubre de 2026; en 6.12.113, 6.6.159, 6.1.190, 5.15.223 y 5.10.272 el 15 de octubre; y 7.3 lo incluyó el 18 de octubre. Las ramas que llegaron a fin de vida antes de 5.10 no reciben parche upstream.

El problema es el de siempre: tu servidor no corre 6.12.113, corre el kernel de tu distribución. Al 29 de octubre, según la fuente original:

Ubuntu: el tracker lista el paquete linux como Vulnerable en todas las versiones. En 26.10, 26.04, 24.04 y 22.04 agrega work in progress; 20.04, 18.04 y 16.04 solo dicen Vulnerable. Sin Ubuntu Security Notice publicado.
Red Hat: RHEL 8, 9 y 10 y OpenShift Container Platform 4 figuran como afectados, sin parche. RHEL 6 y 7 no están afectados.
Debian: corregido en 12 bookworm y 13 trixie.
SUSE: corregido en SLES 16.0 y en los kernels LTSS de 15 SP4, SP5 y SP6; 15 SP7 en progreso.
Oracle Linux: errata de UEK para Oracle Linux 7 a 10 desde el 16 de octubre.
Amazon Linux: corregido en los paquetes kernel6.18 (24 de octubre) y kernel6.12 (29 de octubre) de Amazon Linux 2023; el paquete kernel por defecto y todo Amazon Linux 2 siguen Pending Fix.

Las puntuaciones también difieren, y eso importa para priorizar. El CNA del kernel dice 9.8. Red Hat lo baja a 8.1 y SUSE, Oracle y Amazon también lo puntúan 8.1; Ubuntu lo clasifica High. La diferencia está en la complejidad del ataque: los vendors la consideran alta, el CNA la considera baja porque ambos lados de la carrera los induce el atacante. Que un vendor puntúe menos no es razón para esperar: el exploit de laboratorio de Anthropic logra una shell root remota en al menos una configuración.

¿Qué significa esto para tu startup?

Tres cosas concretas, y ninguna requiere un equipo de seguridad dedicado.

Primero: los contenedores no te salvan. Un contenedor corre sobre el kernel del host. Actualizar la imagen de tu app no cambia absolutamente nada. Si corres Kubernetes, el parche va en los nodos, y el reboot también.

Segundo: mira quién tiene un listener MPTCP. El exploit funcional de Anthropic necesita un servidor con listener de multipath TCP. MPTCP es opt-in: una aplicación tiene que pedirlo al abrir el socket. Pero hay una trampa para equipos que usan Go: según el equipo de seguridad de Go, desde Go 1.24 los programas de Go piden MPTCP por defecto para los sockets donde escuchan. Si tu backend está en Go y actualizaste la toolchain, es probable que tengas listeners MPTCP sin haberlo decidido.

Tercero: el bug no es exclusivo de MPTCP. El mismo equipo de Go advirtió que el problema de fondo no es específico de MPTCP y que los sistemas sin esos listeners también pueden ser vulnerables a ataques similares. Desactivar MPTCP por programa es, en sus palabras, una mitigación frágil: basta un listener expuesto para dejar el sistema vulnerable.

Acciones que puedes ejecutar hoy

Haz un inventario de kernels en los hosts, no dentro de los contenedores. Corre uname -r en cada host y nodo, y compáralo con el estado de tu distribución, no con el número upstream. Si el kernel instalado es más nuevo que el que está corriendo, el parche no está activo hasta que reinicies.
Busca listeners MPTCP. ss -M lista solo sockets MPTCP: un resultado vacío significa que no tienes ninguno. Ojo: net.mptcp.enabled = 1 por sí solo no crea un listener.
Si usas Go, apaga MPTCP mientras parcheas. El equipo de seguridad de Go indica GODEBUG=multipathtcp=0 en el entorno del programa, o godebug multipathtcp=0 en el go.mod del módulo principal. Cualquier código que llame a SetMultipathTCP anula ambas.
Si no puedes parchear todavía, filtra opciones IPv4 en el borde. El tráfico TCP casi nunca lleva opciones IPv4 legítimas, así que descartar esos paquetes debería costar poco. La fuente original propone una regla nft con ip hdrlength gt 5 que corre antes del connection tracking y no toca IPv6 ni tráfico no-TCP. Red Hat también ofrece una mitigación de firewall que filtra paquetes TCP IPv4 entrantes con opciones IP, y advierte probarla contra tus cargas de trabajo antes de desplegarla. Ninguna de las dos arregla el kernel: son puentes hasta el reboot.
Prioriza los hosts con listener MPTCP y los appliances. Los appliances y las imágenes cloud que traen su propio kernel necesitan la actualización de su proveedor, no la de tu distribución.

El parche no está completo hasta que reinicias

Al 29 de octubre, el CVE no aparecía en el catálogo Known Exploited Vulnerabilities de CISA y ningún aviso de vendor reportaba ataques en producción. Ocho repositorios de GitHub ya lo referenciaban, la mayoría herramientas de auditoría o mitigación, y uno decía incluir un disparador de la carrera.

Eso no es consuelo. El aviso de Intersect, la organización de Cardano, pidió a los operadores de stake pools parchear y reiniciar tanto block producers como relays, y la documentación de Cardano recomienda mantener los block producers conectados solo a relays propios o de confianza. Si tu startup corre nodos, validadores o cualquier servicio con puerto TCP expuesto a internet, el cálculo es el mismo.

El mensaje para founders es incómodo pero simple: la parte difícil de esta vulnerabilidad no es el arreglo, son cuatro líneas. La parte difícil es saber qué hosts, nodos y appliances corren qué kernel, y cuáles pueden reiniciarse esta semana. Esa lista conviene tenerla antes de la próxima, no durante.