Hay fallas que nacen en un descuido de hace años y que recién se revelan cuando el mundo ya cambió a su alrededor. Akamai, que administra servidores bajo la marca Linode, avisó a sus clientes que una condición de carrera en el kernel de Linux, identificada como CVE-2026-98432, podría permitir a un atacante remoto tomar control de una máquina. La empresa dice no tener constancia de explotación en su propia infraestructura, pero la tarea de cerrar la puerta recae ahora en quienes operan sus propios servidores. Lo que vuelve el episodio significativo es que la vulnerabilidad fue encontrada con ay
CVE-2026-98432: Akamai investiga un fallo crítico en el kernel de Linux y pide parchear ya
Akamai no puede actualizar el kernel de tu instancia por ti
Mark
¿Qué cambia con este aviso de Akamai para quien tiene servidores en Linode?
Mimi
Que la plataforma está mitigada por su lado, pero el kernel de cada instancia lo actualiza el cliente. Akamai lo dijo claro: aplicar los parches del sistema operativo.
Mark
¿Y por qué hay un 9.8 por un lado y un 5.9 por otro?
Mimi
Describen el mismo bug con supuestos distintos sobre la dificultad de explotarlo. El equipo del kernel considera baja la complejidad; Red Hat, Oracle, SUSE y Amazon la consideran alta.
Luke
Conviene precisar: Akamai dice que no tiene evidencia de explotación en su plataforma. Eso no es lo mismo que afirmar que no ocurrió, y la propia empresa sigue analizando otros impactos.
Mark
¿Qué papel juega la inteligencia artificial?
Mimi
Anthropic dice que Claude escribió un exploit funcional tras un prompt inicial. Según CSO Online, tardó unos 53 minutos hasta obtener root.
Luke
Ese dato viene de Anthropic y de la cobertura que lo cita. No tenemos una verificación independiente del tiempo, y el exploit apunta a servidores con listener MPTCP, no a cualquier Linux.
Mark
¿Qué es lo que más se pasa por alto?
Mimi
Que desde Go 1.24 los programas activan MPTCP por defecto. Un servicio en Go puede estar expuesto sin que el equipo lo sepa.
Luke
Y la mitigación de desactivar MPTCP la llama frágil el propio equipo de Go. Además, no sabemos cuándo llegarán los kernels corregidos de Ubuntu y RHEL; Red Hat habló de una actualización futura.
Le Pouls
- Una condición de carrera en el kernel de Linux permite leer memoria ya liberada y, en el peor escenario, ejecutar comandos como root sin credenciales.
- Un modelo de IA de Anthropic produjo un exploit funcional en unos 53 minutos, y eso reduce el margen de tiempo que tienen los administradores.
- Akamai despliega mitigaciones en su plataforma, pero no puede parchear el kernel de cada instancia de cliente.
- Los proveedores discrepan en la gravedad, de 5.9 en Red Hat a 9.8 en el puntaje del kernel, mientras Ubuntu y RHEL aún no publicaban kernels corregidos al 29 de octubre.
- Los equipos corren para auditar versiones, revisar listeners MPTCP expuestos y planificar ventanas de mantenimiento antes de que la explotación se generalice.
Hay fallas que nacen en un descuido de hace años y que recién se revelan cuando el mundo ya cambió a su alrededor. Akamai, que administra servidores bajo la marca Linode, avisó a sus clientes que una condición de carrera en el kernel de Linux, identificada como CVE-2026-98432, podría permitir a un atacante remoto tomar control de una máquina. La empresa dice no tener constancia de explotación en su propia infraestructura, pero la tarea de cerrar la puerta recae ahora en quienes operan sus propios servidores. Lo que vuelve el episodio significativo es que la vulnerabilidad fue encontrada con ayuda de una inteligencia artificial, lo que obliga a repensar cuánto tiempo queda entre el hallazgo y el abuso.
Akamai publicó en su página de estado un aviso dirigido a sus clientes sobre CVE-2026-98432, una vulnerabilidad de ejecución remota de código en el kernel de Linux. La compañía activó mitigaciones en su plataforma de cómputo, la misma que opera bajo la marca Linode, y pidió a los usuarios aplicar cuanto antes las actualizaciones que publique su proveedor. No tiene, por ahora, evidencia de explotación en Akamai Compute, pero no puede actualizar el kernel de cada instancia: ese trabajo le corresponde al cliente.
El fallo está en el código que establece nuevas conexiones TCP IPv4. Cuando una conexión se completa, el kernel traspasa 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, el kernel lee memoria liberada. El puntaje de 9.8 sobre 10 supone un atacante que gana la carrera con opciones Record Route o Timestamp, y en ese caso podría filtrar memoria, corromperla o tumbar el sistema.
Lo que encendió las alarmas fue el origen del exploit. Anthropic informó que su modelo Claude escribió, a partir de un prompt inicial, una prueba de concepto que permite a un atacante remoto sin credenciales obtener root en servidores con un listener de Multipath TCP. Según los datos citados, el proceso tomó unos 53 minutos.
Las evaluaciones de gravedad no coinciden. Red Hat la considera moderada, con 5.9, porque la carrera es difícil de ganar y el resultado más probable sería un crash. Otros vendors la ubican en 8.1 y Amazon en 7.0. La diferencia se explica sobre todo por la complejidad que atribuye cada uno al ataque.
Al 29 de octubre, Debian, Oracle Linux, SUSE y Amazon Linux ya tenían kernels corregidos en algunas versiones, mientras Ubuntu y RHEL seguían sin ellos. Red Hat dejó sus arreglos para una actualización futura. La corrección existe en varias ramas del kernel y fue publicada por los desarrolladores diez días antes del CVE.
Un detalle que muchos pasan por alto: desde Go 1.24, los programas en Go activan MPTCP por defecto, así que un servicio escrito en Go podría exponer el vector sin que nadie lo haya configurado. El equipo de seguridad de Go recomienda desactivarlo, aunque advierte que esa medida es frágil, porque el problema de fondo no es exclusivo de MPTCP.
La recomendación es la misma para todos: saber qué kernel corre en cada servidor, revisar los listeners MPTCP expuestos y actualizar en cuanto la distribución publique la corrección. En el caso de Ubuntu y RHEL, eso exige planear una ventana de mantenimiento y seguir de cerca los avisos de cada proveedor.
Akamai publicó en su página de estado un aviso para clientes sobre CVE-2026-98432, una vulnerabilidad de ejecución remota de código en el kernel de Linux. La compañía activó un proceso de mitigación sobre su plataforma de cómputo, la misma que opera bajo la marca Linode, y pidió a los usuarios que apliquen las actualizaciones del sistema operativo de su proveedor upstream en cuanto estén disponibles.
El mensaje es tranquilizador, pero no definitivo. Akamai afirma que por ahora no tiene evidencia de que el fallo haya sido explotado en Akamai Compute. Dice estar desplegando mitigaciones para el vector de ataque conocido mientras analiza otros posibles impactos. La consecuencia práctica para quien corre producción en Linode es que Akamai no puede actualizar el kernel de cada instancia: ese parche le toca al cliente.
El fallo es una condición de carrera en el código del kernel que establece nuevas conexiones TCP IPv4. Al completarse 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 aún usa esas opciones para responder a una solicitud retransmitida, el kernel lee memoria ya liberada: un use-after-free. El equipo de CVE del kernel le asignó 9.8 sobre 10 en la escala CVSS, según The Hacker News. Ese puntaje supone un atacante que envía una solicitud TCP con opciones IPv4 Record Route o Timestamp y la reenvía para ganar la carrera. En ese escenario podría filtrar memoria del kernel, corromperla o tumbar el sistema.
Lo que encendió las alarmas 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 acredita como reportante a Xinyang Ge, investigadora de Anthropic. Según CSO Online, la prueba de concepto tardó unos 53 minutos desde la fuga inicial de memoria hasta los comandos con privilegios de root; el post de Anthropic precisa 48 minutos para filtrar una dirección del kernel y cinco más para ejecutar comandos.
Las puntuaciones de severidad no coinciden. Red Hat lo califica como Moderate con 5.9 en su página de CVE, con el argumento de que la carrera es difícil de ganar y lo más probable es un crash, sin impacto demostrado en confidencialidad o integridad. Su archivo de aviso legible por máquina, actualizado el 29 de octubre, lo lista como Important con 8.1. Oracle y SUSE también ponen 8.1 y Amazon, 7.0. La diferencia radica en un solo factor: la complejidad del ataque, alta para los vendors y baja para el equipo del kernel.
El estado de los parches era desigual al 29 de octubre, según el relevamiento de The Hacker News. Debian, Oracle Linux, SUSE y Amazon Linux habían publicado kernels corregidos, al menos para algunas versiones. Ubuntu (22.04, 24.04, 26.04 y 26.10) y RHEL (8, 9 y 10, además de OpenShift 4) aún no los tenían; Red Hat dijo que sus arreglos quedaban diferidos a una actualización futura. Quien compile su propio kernel encontrará la corrección 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 lo parchearon el 5 de octubre, diez días antes de publicarse el CVE; el arreglo hace que el kernel espere a que otras CPU terminen de leer las opciones antes de liberarlas.
Hay un detalle 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 de escucha, de modo que un servicio escrito en Go podría exponer el vector sin que nadie lo haya pedido. Recomiendan GODEBUG=multipathtcp=0 en el entorno, o godebug multipathtcp=0 en el go.mod, aunque ellos mismos llaman frágil a esa mitigación: un solo listener MPTCP expuesto deja el sistema vulnerable y el bug de fondo no es específico de MPTCP.
La recomendación de todos los equipos es la misma: auditar qué kernel corre cada servidor, revisar si hay listeners MPTCP expuestos y actualizar a un kernel corregido en cuanto la distribución lo publique. Para Ubuntu y RHEL, eso implica planificar una ventana de mantenimiento y vigilar los avisos de cada vendor.
Citations marquantes
Akamai no tiene evidencia de que la vulnerabilidad haya sido explotada en la plataforma Akamai Compute y pide aplicar las actualizaciones del proveedor upstream.— Akamai, aviso en su página de estado
Red Hat dijo que sus arreglos estaban diferidos a una actualización futura.— Red Hat, según The Hacker News
Envie de l'histoire complète ?
Lire l'original sur El Ecosistema Startup ↗
World & Diplomacy