El 30 de octubre, Red Hat publicó un boletín que identifica RHEL 8, 9 y 10, y Red Hat OpenShift Container Platform, como afectados por CVE-2026-98432. La medida de filtrado que propone reduce la exposición, pero Red Hat advierte que no evita por completo la vulnerabilidad y no sustituye la instalación de un kernel corregido. En su página CVE consultada el 1 de noviembre, la compañía califica el problema como crítico y le asigna una puntuación CVSS 3.1 de 9,8.

Qué cubre la medida de Red Hat

CVE-2026-98432 es un fallo de uso después de liberar memoria en el manejo de conexiones TCP sobre IPv4 en el kernel Linux. Red Hat describe una condición de carrera durante el procesamiento simultáneo de solicitudes TCP retransmitidas o la migración de sockets. Un atacante remoto no necesita privilegios ni interacción del usuario, aunque debe acertar el momento preciso para activar el fallo. Red Hat menciona como posibles efectos una caída del sistema, corrupción de memoria y ejecución remota de código.

La regla de nftables de Red Hat descarta paquetes TCP IPv4 entrantes que llevan opciones en la cabecera IP. La compañía indica que el filtro reduce la exposición, pero no bloquea todas las vías del fallo y puede interrumpir cargas de trabajo necesarias. Por eso, no equivale a corregir el kernel. El boletín de seguridad de Red Hat detalla los productos afectados y los límites de la medida; su página CVE muestra la clasificación crítica y la puntuación 9,8.

Amazon Linux marca como corregidas sus familias de paquetes afectadas

La página oficial de Amazon Linux, modificada el 30 de octubre, marca como corregidas siete familias de paquetes: Amazon Linux 2 core y Extras 5.4, 5.10 y 5.15; y Amazon Linux 2023 default, kernel6.12 y kernel6.18. La misma página clasifica el problema como Importante y le asigna CVSS 3.1 de 8,1. Es la valoración que Amazon muestra para sus paquetes; Red Hat presenta la suya para sus productos. El aviso de Amazon Linux enumera los paquetes y su estado.

MPTCP aparece en la demostración, no define por sí solo el fallo

El 27 de octubre, Anthropic describió una prueba de concepto en la que Claude logró ejecutar comandos como root en un servidor Linux con un socket de escucha MPTCP. Anthropic informó que su prueba tardó 48 minutos en filtrar un puntero del kernel y otros cinco minutos en alcanzar la ejecución de comandos. Esos tiempos corresponden a la demostración comunicada por la empresa. NeoTeo ya había cubierto la demostración en su artículo sobre las cadenas de exploits de Anthropic.

MPTCP, o TCP multipath, es la configuración del socket que utilizó esa prueba. El Go Security Team señaló que el fallo subyacente del kernel no es específico de MPTCP y que podrían existir vías de ataque sin un socket de escucha MPTCP. Además, Go 1.24 activa MPTCP por defecto en sockets de escucha para Linux. El equipo considera frágil desactivarlo aplicación por aplicación y recomienda usar un kernel corregido. La advertencia del Go Security Team explica el valor predeterminado y el alcance de esa medida.

Qué dicen Sophos y OpenVPN sobre sus productos

Sophos confirmó el 30 de octubre que Sophos Firewall está afectado. La compañía dijo que el producto tiene MPTCP desactivado, lo que puede reducir el riesgo, y que su equipo de ingeniería evaluaba parches del kernel para una futura versión de SFOS. La respuesta de Sophos no presenta la configuración MPTCP como una corrección del fallo.

OpenVPN indica que las instalaciones estándar de Access Server usan TCP de una sola ruta en la interfaz web, los procesos de OpenVPN y SSH, sin exponer sockets de escucha MPTCP. Aun así, recomienda instalar el kernel corregido de la distribución y reiniciar el sistema anfitrión, que puede seguir siendo vulnerable. La guía de OpenVPN para Access Server limita esa descripción a sus instalaciones estándar.

En debates de administradores de sistemas, algunos participantes señalaron la carga que supone probar y priorizar parches, sobre todo para equipos pequeños. (r/sysadmin y r/cybersecurity).