Se descubrió un fallo de seguridad llamado SCTPhantom (CVE-2026-64564) en el código de red SCTP de Linux, presente desde 2008. Esta vulnerabilidad permite obtener acceso root en el host y escapar de contenedores, afectando a diversas distribuciones como Ubuntu y RHEL. Ya existen parches disponibles en versiones recientes del kernel, por lo que se recomienda actualizar los sistemas afectados.





Un error de tipo use-after-free en el código de red SCTP de Linux puede convertirse en un acceso total de root en un host, y los investigadores de Tencent afirman que lo utilizaron para escapar de un contenedor y llegar a la máquina subyacente.

El fallo ha existido desde 2008. La solución ya se ha implementado: los núcleos estables 7.1.6, 6.18.42, 6.12.101 y 6.6.148, lanzados el 3 de agosto, lo corrigen. Si ejecutas un núcleo más antiguo con SCTP accesible, deberías actualizar.

Rastreado como CVE-2026-64564 y nombrado SCTPhantom por quienes lo descubrieron, el fallo se reveló públicamente el 6 de agosto, dos días después de que el equipo de CVE del kernel se lo asignara. No ha aparecido código de exploit público al momento de escribir esto, y no se encontró ninguna entrada para el fallo en el catálogo de Vulnerabilidades Explotadas Conocidas de la CISA hasta el 7 de agosto.

El fallo es local, no remoto, y requiere que SCTP sea accesible en el objetivo, lo que limita la exposición. Donde se cumplieron esas condiciones, Tencent Zhuque Lab informa que obtuvo root en las compilaciones de kernel que probó para Debian 13, Ubuntu 24.04, Rocky Linux 9, RHEL 9 y OpenCloudOS.

SCTP es un protocolo de transporte que permite que una conexión se ejecute a través de varias rutas de red a la vez. Una función complementaria, la reconfiguración dinámica de direcciones, permite que un par añada o elimine esas direcciones a mitad de la conexión.

El error es una confusión de identidad: el kernel verifica una solicitud de eliminación comparándola con la dirección de origen del paquete, pero actúa sobre una ruta que eligió usando una dirección diferente dentro del mensaje. Según el propio aviso del kernel [https://nvd.nist.gov/vuln/detail/CVE-2026-64564], un mensaje puede llevar una dirección, una eliminación para esa misma dirección y luego una eliminación comodín. Esa secuencia libera la ruta y luego reutiliza el puntero muerto, dejando la conexión apuntando a una memoria que el kernel ya ha liberado.

El parche rechaza una eliminación dirigida a la ruta sobre la cual se está procesando el mensaje. El error se remonta a Linux 2.6.25 en 2008 y ha estado presente en cada kernel lanzado desde entonces.

Fuente: Fourier [https://x.com/Khanmlgb/status/2085332680636584174] en X.

La afirmación de escape de contenedor de Tencent se basa en sus propias pruebas. En su informe [https://matrix.tencent.com/en/2026/08/06/sctphantom-CVE-2026-64564], el laboratorio dice que una versión temprana de su exploit necesitaba que los sysctls net.sctp.addip_enable y net.sctp.addip_noauth_enable estuvieran activados, lo que hacía que CAP_NET_ADMIN pareciera un requisito previo. Más tarde encontró una ruta que deja ambos intactos activando las funciones por socket en su lugar.

El laboratorio dice que su prueba de escape mantuvo el perfil seccomp predeterminado y no concedió ni CAP_NET_ADMIN ni CAP_SYS_ADMIN. Según sus cuentas, seis de ocho intentos alcanzaron root en el host.

Nadie fuera del laboratorio ha reproducido nada de esto, y el informe no menciona el runtime de contenedor contra el que probó. El propio laboratorio señala que el acceso al socket, los perfiles seccomp y la política de user-namespace desplazan la exposición a otros lugares. Un aviso de openKylin [https://bbs.openkylin.top/t/topic/173441] que cubre el mismo error no llega más allá de un kernel panic y denegación de servicio.

El número de severidad también es incierto. Tencent lo calificó con 8.5 bajo CVSS v4.0. NVD no había asignado ni una puntuación ni una clasificación de debilidad hasta el 7 de agosto.

Los proveedores a menudo adaptan los parches sin pasar a una nueva versión upstream, por lo que una cadena de versión del kernel por sí sola no te dirá si estás protegido; consulta el rastreador de tu distribución. Un segundo use-after-free de transporte colgante en el mismo código [https://kernel.googlesource.com/pub/scm/linux/kernel/git/netdev/net-next/+/c9158ceaf27780ef64534ad72f44ffde3f8ccc49] fue parcheado el 6 de agosto, después de que se lanzaran las versiones estables del 3 de agosto, por lo que esos kernels no lo incluyen. Donde SCTP no sea necesario, bloquear el módulo elimina la superficie de ataque por completo.

Tencent atribuye el hallazgo a Corvus AI, una canalización de investigación multi-agente que construyeron para el trabajo con el kernel, convirtiendo a SCTPhantom en el último de una serie de fallos del kernel largamente dormidos que han salido a la luz con asistencia de máquinas este año, junto a GhostLock en julio. También coincide el mismo día que Zapscape, un escape de KVM no relacionado, y las mismas cuatro versiones estables llevan ambas correcciones.

Fuente:
THN