CVE-2026-98432: Linux TCP y el exploit de Anthropic

CVE-2026-98432: la brecha entre un 9.8 y un 5.9

El equipo de CVE del kernel de Linux le puso 9.8 sobre 10 a CVE-2026-98432, un use-after-free en la ruta del handshake IPv4 de TCP. El mismo error aparece con 5.9 en la página de Red Hat y con 8.1 en su archivo de avisos legible por máquina, según el relevamiento de The Hacker News. Esa diferencia de más de tres puntos no es un detalle burocrático: define si tu equipo parchea esta semana o el próximo trimestre.

La explicación es concreta. El vector del kernel asume complejidad de ataque baja porque, según ese análisis, ambos lados de la carrera son inducidos por el atacante. Red Hat sostiene lo contrario: que la carrera es difícil de ganar y que el resultado más probable es un crash del sistema, no corrupción de memoria. Amazon lo puntúa 7.0, y Oracle y SUSE 8.1. Ninguno de esos números cambia el hecho de fondo: el fallo es alcanzable por red y las distribuciones más usadas en servidores todavía no tenían kernel corregido al 29 de octubre.

Para quien administra producto, la lectura útil es simple: un CVSS no es una decisión de parcheo, es un insumo para tomarla.

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 →

Cómo funciona el use-after-free en el handshake TCP

Cuando un servidor Linux recibe un SYN, el kernel no asigna un socket completo: crea un request socket liviano que guarda el estado mínimo para validar el handshake. Cuando llega el ACK final, ese estado se transfiere al socket hijo.

El problema está en las opciones IPv4. En la ruta afectada, el puntero ireq_opt del request socket se convierte en el inet_opt del socket hijo sin copiar el objeto. La transferencia evita una copia, pero hace que la vida útil de una misma asignación cruce el límite entre dos sockets.

Si mientras tanto otra CPU procesa un SYN retransmitido de la misma conexión, construye un SYN-ACK leyendo esas opciones dentro de una sección crítica RCU. El path de lectura asume que el objeto sigue vivo; el destructor lo liberaba con kfree() común, sin esperar a que los lectores RCU terminaran. Resultado: una CPU puede seguir leyendo memoria que ya volvió al allocator.

La corrección upstream reemplaza la liberación inmediata por kfree_rcu(), que difiere la reclamación hasta que pasa un grace period de RCU. Según The Hacker News, el parche se aplicó el 5 de octubre, diez días antes de que se publicara el CVE, y la corrección se atribuye al investigador de Anthropic Xinyang Ge. El fallo se introdujo en Linux 4.4, así que la historia afectada abarca muchas ramas mantenidas.

Un dato que suele circular mal: la ruta principal del bug es específica de IPv4 porque la función equivalente en IPv6 copia las opciones en lugar de transferir el puntero. Decir que "IPv6 no está afectado" es correcto para ese path, pero demasiado amplio como regla general.

Qué demostró Anthropic y qué no prueba

Anthropic publicó el 27 de octubre que su modelo escribió un exploit que, contra un servidor Linux con un listener de Multipath TCP (MPTCP) — la extensión que permite que una conexión use varias rutas de red a la vez — logra ejecutar comandos como root de forma remota y sin credenciales.

La cadena tiene dos etapas. Primero, la carrera hace que el kernel devuelva bytes extra al atacante hasta filtrar una dirección de kernel, lo que rompe la aleatorización de memoria (KASLR). Segundo, el mismo fallo desborda un buffer y sobrescribe un puntero de callback con la dirección de un payload ya colocado en memoria del kernel. Cuando el kernel llama a ese puntero, se ejecuta el comando.

Los tiempos importan para calibrar la urgencia: según Anthropic, filtrar la dirección del kernel tomó 48 minutos y llegar a ejecución de comandos otros 5 minutos. Una carrera perdida solo falla esa conexión y no tumba el host, así que el atacante puede reintentar.

Ahora, los límites. El post no incluye el código del exploit, ni la versión de kernel, ni la configuración exacta probada. Tampoco dice que un servicio TCP ordinario, sin MPTCP, sea explotable de la misma forma. Y al 29 de octubre ni los avisos de los vendors ni el registro CVE reportaban ataques en producción.

Qué distribuciones ya publicaron el parche

La respuesta correcta no sale de comparar uname -r contra una lista upstream. Las empresas backportean correcciones manteniendo versiones base viejas, así que un escáner de versiones produce falsos positivos y falsos negativos en la misma corrida.

Estado según The Hacker News al 29 de octubre:

Debian publicó paquetes corregidos (trixie el 16 de octubre; bookworm el 17 y el 22).
Oracle Linux (kernel UEK) publicó sus erratas el 16 de octubre.
Amazon Linux 2023 corrigió el paquete kernel6.18 el 24 de octubre y el kernel6.12 el 29.
SUSE Linux Micro 6.2 y openSUSE Leap 16.0 tienen paquete corregido; SLES 15 SP7 seguía en progreso.
Ubuntu (22.04, 24.04, 26.04 y 26.10 LTS) marcaba prioridad alta con trabajo en curso y sin paquete publicado.
RHEL 8, 9, 10 y OpenShift 4: corrección diferida a una actualización futura, sin fecha.

Para kernels compilados a mano, las primeras versiones estables corregidas son 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 y la línea 7.3. El equipo de CVE del kernel aclara que no soporta la práctica de aplicar parches individuales.

Por qué el cuello de botella ya no es encontrar fallos

Hay un dato de contexto que cambia cómo se lee esta noticia. Según Google Threat Intelligence Group, citado por Help Net Security, las divulgaciones mensuales de CVE se duplicaron en 2026, de 5.045 en enero a 10.740 en agosto, y la mitad de las vulnerabilidades identificadas como descubiertas por IA derivan en ejecución remota de código, contra 26% de las halladas por otros medios.

La empresa de ciberseguridad ThreatDown, según THE Journal, reportó que en septiembre de 2026 los vendors resolvieron 998 CVE alrededor del Patch Tuesday, contra 96 en el mismo período del año anterior, y que el promedio móvil de tres meses de vulnerabilidades parcheadas en el kernel de Linux se triplicó interanualmente.

El problema es que el descubrimiento se aceleró más rápido que la capacidad de desplegar correcciones. El mismo reporte cita el Data Breach Investigations Report 2026 de Verizon, que encontró que el 35% de las vulnerabilidades explotadas activamente seguía sin parchear 28 días después.

Para una startup, eso significa que el riesgo ya no está en enterarse tarde de un CVE. Está en la ventana entre saberlo y tenerlo instalado en cada nodo.

¿Qué significa esto para tu startup?

Si tu producto corre sobre Linux, este CVE te toca aunque no uses MPTCP, porque el path principal afecta el handshake IPv4 ordinario. Estas son las acciones concretas:

Inventaría qué kernel corre de verdad. En cada host: uname -r, cat /etc/os-release y el paquete instalado (dpkg-query -W 'linux-image*' en Debian/Ubuntu, rpm -q kernel kernel-core en RHEL). La versión base no es evidencia; el aviso del vendor sí.
Revisa si expones MPTCP. sysctl net.mptcp.enabled, ip mptcp endpoint show e ip mptcp limits show. Es la configuración que la investigación pública validó, así que encabeza la cola.
Confirma que reiniciaste el kernel nuevo. Instalar el paquete no cambia el kernel en ejecución. Compara uname -r con la imagen instalada después del reboot y hazlo nodo por nodo en clústeres.
No actualices solo la imagen del contenedor. Los contenedores comparten el kernel del host. En Kubernetes gestionado, esto suele requerir una actualización de la imagen de nodo o una ventana de mantenimiento del proveedor.
Trata el live patching como no confirmado salvo que el vendor lo asocie explícitamente a este CVE. Si no hay confirmación, instala el kernel corregido y reinicia.

Y una nota de higiene operativa: no reproduzcas la cadena en producción. Validar alcanza con ss -lntp para ver listeners, la política de red y el aviso del vendor. Ganar la carrera no es un test de seguridad, es un incidente.

El patrón que deja esta noticia es más importante que el CVE puntual. Si la IA acelera el descubrimiento de fallos de forma estructural, la ventaja competitiva de un equipo de infraestructura deja de ser enterarse primero y pasa a ser parchear más rápido sin romper el servicio.