CVE-2026-98432: fallo crítico en Linux y alerta de Akamai

Akamai confirma que investiga CVE-2026-98432 en su plataforma de cómputo

Akamai reconoció el fallo CVE-2026-98432, una vulnerabilidad de ejecución remota de código en el kernel de Linux, y activó un proceso de mitigación sobre su plataforma de cómputo, la misma que opera bajo la marca Linode. La compañía publicó el aviso en su página de estado y pidió a los clientes que apliquen las actualizaciones de sistema operativo de su proveedor upstream en cuanto estén disponibles.

El mensaje central del aviso es tranquilizador pero no definitivo: Akamai afirma que, por ahora, no tiene evidencia de que la vulnerabilidad haya sido explotada en la plataforma Akamai Compute. La empresa dice estar desplegando mitigaciones para el vector de ataque conocido mientras sigue analizando otros posibles impactos.

Para un founder que corre producción en Linode, la lectura práctica es simple: hay un fallo crítico en el kernel, tu proveedor está trabajando en él, pero la pelota del parche del sistema operativo está en tu cancha. Akamai no puede actualizar el kernel de tu instancia por ti.

¿Y esto cómo se aplica en tu negocio?

Dueños de negocio de Latinoamérica y España usan un agente de IA para ganar más y recuperar su tiempo. El Kit «tu mano derecha con IA» te muestra cómo en un video de 11 minutos, con una ficha para armar el tuyo. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

¿Qué es CVE-2026-98432 y por qué se le asigna un 9.8?

El fallo es una condición de carrera en el código del kernel de Linux que establece nuevas conexiones TCP IPv4. Cuando se completa una conexión, el kernel transfiere las opciones IP de la solicitud pendiente al nuevo socket sin copiarlas. Si ese socket se destruye mientras otra CPU todavía usa esas opciones para responder a una solicitud retransmitida, el kernel termina leyendo memoria ya liberada: un use-after-free.

El equipo de CVE del propio kernel le asignó un 9.8 sobre 10 en la escala CVSS, según reportó The Hacker News. Ese puntaje asume un atacante que envía una solicitud TCP con opciones IPv4 Record Route o Timestamp y luego la reenvía para ganar la carrera. Bajo ese escenario, el fallo podría devolver memoria del kernel al atacante, corromperla o tumbar el sistema.

El detalle que encendió las alarmas en la industria es quién encontró el exploit. Anthropic publicó el 27 de octubre que su modelo Claude escribió, tras un prompt inicial, un exploit funcional que permite a un atacante remoto sin credenciales ejecutar comandos como root en servidores Linux con un listener de Multipath TCP (MPTCP). El parche del kernel acredita a la investigadora de Anthropic Xinyang Ge como quien reportó el bug.

Según CSO Online, la prueba de concepto de Anthropic tardó aproximadamente 53 minutos en pasar de la fuga inicial de memoria a la ejecución de comandos con privilegios de root. En su propio post, Anthropic detalla que filtrar una dirección del kernel tomó 48 minutos y llegar a la ejecución de comandos, 5 minutos más.

Las puntuaciones no coinciden: 9.8 contra 5.9

Aquí hay una lección útil sobre cómo leer severidades. Mientras el equipo del kernel puntúa el fallo en 9.8, Red Hat lo califica como Moderate con 5.9 en su página de CVE, argumentando que la carrera es difícil de ganar y que lo más probable es un crash del kernel, sin impacto de confidencialidad o integridad demostrado.

Sin embargo, el archivo de aviso legible por máquina de Red Hat, actualizado el 29 de octubre, lista el impacto como Important con 8.1. Oracle y SUSE también puntúan 8.1, y Amazon lo deja en 7.0, según The Hacker News. La diferencia entre todas las puntuaciones está en un solo factor: la complejidad del ataque, que los vendors consideran alta y el equipo del kernel, baja.

Traducción para quien no vive de esto: no te fíes de una sola fuente de severidad. Un 5.9 y un 9.8 describen el mismo bug con supuestos distintos sobre qué tan fácil es explotarlo.

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

El estado cambia rápido, pero el panorama al 29 de octubre, según el relevamiento de The Hacker News, era desigual:

Debian, Oracle Linux, SUSE y Amazon Linux ya habían publicado paquetes de kernel corregidos, al menos para algunas de sus versiones.
Ubuntu (22.04, 24.04, 26.04 y 26.10 LTS) y RHEL (8, 9 y 10, más OpenShift 4) seguían sin kernel corregido disponible. Red Hat dijo que sus arreglos estaban "diferidos a una actualización futura".
Si compilas tu propio kernel, el fix está en las 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.

El bug se introdujo en Linux 4.4 y los desarrolladores del kernel aplicaron el parche el 5 de octubre, diez días antes de que se publicara el CVE. El arreglo hace que el kernel espere a que otras CPU terminen de leer las opciones antes de liberarlas.

Un dato que muchos equipos pasan por alto: el equipo de seguridad de Go advirtió el 29 de octubre que, desde Go 1.24, los programas de Go activan MPTCP por defecto en los sockets donde escuchan. Es decir, servicios escritos en Go pueden estar exponiendo el vector sin que nadie lo haya pedido explícitamente.

¿Qué significa esto para tu startup?

Si tu producto corre sobre infraestructura cloud compartida —Linode, AWS, un VPS europeo— este episodio es un recordatorio de dónde está realmente la responsabilidad. El proveedor parchea su plataforma; tú parcheas tus instancias. Nadie lo va a hacer por ti.

Acciones concretas que puedes tomar hoy:

Audita qué kernel corre tu flota. Antes de cualquier otra cosa, necesitas saber si tus servidores están en una versión afectada y si tu distribución ya publicó el paquete corregido. Si usas Ubuntu o RHEL, probablemente todavía no lo tengas: planifica una ventana de mantenimiento y monitorea el aviso de tu vendor.
Revisa si expones listeners MPTCP. El exploit de Anthropic apunta específicamente a servidores con un listener de Multipath TCP. Si no usas MPTCP, vale la pena confirmar que ningún servicio lo esté activando por defecto.
Si tienes servicios en Go, revisa tu configuración. El equipo de seguridad de Go recomienda GODEBUG=multipathtcp=0 en el entorno del programa, o godebug multipathtcp=0 en el go.mod para desactivarlo en tiempo de compilación. Ojo: el propio equipo califica esta mitigación como frágil, porque un solo listener MPTCP expuesto deja el sistema vulnerable y el bug subyacente no es específico de MPTCP.
No confundas mitigación con parche. Desactivar MPTCP reduce superficie de ataque, pero la recomendación de fondo de todos los equipos de seguridad es actualizar a un kernel corregido.

Conclusión

CVE-2026-98432 es un caso que vale la pena estudiar más allá del parche. Un modelo de IA encontró y explotó una vulnerabilidad de kernel que llevaba años en el código, y lo hizo en menos de una hora de trabajo efectivo. Eso cambia la economía de la seguridad ofensiva: lo que antes requería semanas de un investigador humano ahora puede salir de un prompt.

Para los founders, la conclusión operativa es incómoda pero clara. La velocidad a la que aparecen exploits funcionales va a seguir subiendo, y tu capacidad de reaccionar depende de cuánto tardas en saber qué versión corre en cada servidor. Si no puedes responder esa pregunta en minutos, ese es el problema a resolver esta semana, no el CVE.