CloudLinux publica el estado de CVE-2026-98432, un fallo de tipo use-after-free en la implementación de TCP sobre IPv4 del kernel Linux que puede alcanzarse por cualquier atacante que pueda conectarse a un puerto IPv4 abierto del servidor, sin necesidad de cuenta. Según la nota, la explotación requiere ganar una carrera de temporización (race) dentro del kernel, lo que complica su aprovechamiento en la práctica.
Qué cambia y a quién afecta
El fallo reside en la fase de establecimiento de conexiones TCP: las opciones IPv4 (por ejemplo, timestamp o record route) se almacenan con la conexión pendiente y se comparten entre distintas estructuras internas sin copia. Si ocurre una retransmisión de un mismo paquete SYN y otro CPU procesa esa retransmisión mientras el primer flujo completa el handshake y libera la conexión, puede producirse una lectura de memoria ya liberada (use-after-free).
CloudLinux indica que el código vulnerable apareció en Linux 4.4, por lo que todos sus kernels a partir de esa base incorporan la vulnerabilidad salvo CloudLinux 7. Multipath TCP (MPTCP) no está activado por defecto en CloudLinux 8, 9 y 10, y el informe original (de Anthropic) afirma haber generado un exploit localmente para servidores que ejecuten un listener MPTCP; sin embargo, el equipo de CloudLinux no ha podido reproducir la explotación remota con privilegios root que se describe, y no hay exploit público ni informes de explotación en entornos reales.
Qué debe hacer el administrador
La única mitigación completa señalada por CloudLinux y por Red Hat es aplicar la corrección del kernel o un livepatch; no existe una medida temporal sencilla, universal y estable que cumpla los criterios de desplegado masivo. Por tanto, los administradores deben:
- Verificar si su distribución CloudLinux está afectada (todas las versiones desde Linux 4.4 salvo CloudLinux 7).
- Actualizar a los kernels corregidos en la medida en que estén disponibles para su stream. CloudLinux ha publicado kernels con la corrección en algunos streams y describe un despliegue gradual; en otros casos todavía está en preparación o depende de parches publicados por las distribuciones que suministran el kernel (por ejemplo, Canonical para CloudLinux sobre Ubuntu 22.04).
- Considerar el uso de livepatching (KernelCare o equivalentes) si reiniciar y aplicar un kernel nuevo no es viable por motivos de disponibilidad: CloudLinux prepara livepatches que aplican la corrección en caliente y evitan reinicios.
- Tras aplicar la actualización y reiniciar (cuando corresponda), comprobar la versión del kernel con uname -r y confirmar que el kernel instalado corresponde al listado de kernels corregidos del stream.
- Si usa KernelCare, usar kcarectl –patch-info para verificar que el parche que incluye la CVE está aplicado; kcarectl –info sólo muestra el nivel de parche y puede falsear la apariencia de estado.
Impacto práctico y explicación técnica
En entornos de hosting compartido, es habitual que servicios como web, correo o SSH mantengan puertos IPv4 abiertos. Cualquier puerto TCP accesible puede desencadenar el código vulnerable al procesar un SYN con opciones IPv4. El ataque descrito por quien reportó la CVE consiste en enviar repetidamente SYNs con opciones IPv4 para forzar la condición de carrera; si el atacante pierde la carrera sólo obtiene conexiones fallidas y puede reintentar. Que ese patrón permita ejecutar código a distancia o escalar a root depende de detalles de kernel, configuración y sincronización, y CloudLinux no ha reproducido un exploit funcional en sus kernels.
La solución upstream consiste en garantizar que las opciones sean retenidas hasta que todos los lectores hayan terminado, evitando liberar la memoria mientras todavía se lee. IPv6 evita el problema porque copia las opciones en lugar de compartirlas.
Estado de las correcciones y recomendaciones finales
CloudLinux anuncia kernels corregidos para algunos streams y un despliegue por fases; en otros streams la corrección llega desde las distribuciones proveedoras del kernel (por ejemplo, AlmaLinux o Canonical) o aún está en preparación. Cuando el kernel corregido esté en el repositorio de su stream, una actualización regular lo instalará y será necesario reiniciar para activarlo, salvo que se aplique un livepatch.
Recomendamos a administradores y propietarios de sitios web priorizar la actualización o aplicar livepatches en servidores expuestos a Internet. Mientras no exista evidencia pública de explotación masiva, la dificultad técnica de la explotación no elimina el riesgo: mantener el kernel actualizado es la defensa adecuada.
Lee también:
- Informe de ESET resume actividad de grupos APT en el segundo y tercer trimestre de 2026
- 42% de webs electorales de condados de EE. UU. siguen sin dominio .gov, según informe
Fuente: CloudLinux
