Qué rompe realmente SCTPhantom

CVE-2026-64564 - apodado SCTPhantom por parte de los investigadores que lo han cubierto - es una vulnerabilidad use-after-free dentro de la implementación de SCTP del kernel de Linux, el Stream Control Transmission Protocol usado sobre todo en señalización de telecomunicaciones, algunos sistemas de mensajería financiera y ciertas pilas de red de contenedores y clústeres. El fallo reside en concreto en ASCONF, el código que gestiona la Reconfiguración Dinámica de Direcciones, que permite a una asociación SCTP activa añadir o eliminar direcciones IP sin cerrar la conexión. La CVE se anunció formalmente el 4 de agosto de 2026, tras un proceso de divulgación privada que había comenzado el 12 de julio de 2026.

La causa raíz es una discrepancia de identidad: cuando el kernel procesa una solicitud DEL-IP para eliminar una dirección de una asociación, valida esa solicitud usando la dirección de origen del paquete entrante, mientras que un puntero en caché independiente dentro del kernel sigue guiándose por la dirección indicada en el propio parámetro de la solicitud. Un atacante que construya una secuencia deliberadamente ordenada de fragmentos ASCONF puede aprovechar ese hueco entre ambas comprobaciones para liberar una zona de memoria del kernel mientras un puntero activo aún apunta a ella - la definición de manual de un use-after-free, y uno de los recursos más fiables para convertir un fallo del kernel en ejecución de código real.

Dieciocho años son el titular, no la lección

El código responsable se remonta a Linux 2.6.25, publicado en diciembre de 2007, lo que sitúa el fallo en unos 18 años de antigüedad en el momento en que el Zhuque Lab de Tencent lo encontró. Los investigadores atribuyen el hallazgo a Corvus AI, una canalización autónoma multiagente de investigación de vulnerabilidades que el equipo opera internamente, que señaló la ruta de código ASCONF como merecedora de una revisión manual más profunda. Ese detalle importa casi tanto como el propio fallo: no se trata de una zona del kernel conocida como arriesgada que por fin se audita, sino de un rincón genuinamente poco visitado que nadie examinó a fondo durante casi dos décadas.

Las correcciones estables llegaron el 3 de agosto de 2026 en las ramas del kernel 6.6.148, 6.12.101, 6.18.42 y 7.1.6, y los mantenedores de las distribuciones ya han empezado a incorporarlas a sus propios árboles de paquetes. Esa es la parte de la historia que cubren todos los medios, y también la que menos importa para la mayoría de los lectores. Una brecha de 18 años entre la publicación del fallo y su descubrimiento demuestra que una política de esperar a que llegue el parche ya falló en silencio durante dieciocho años en esta misma ruta de código - no hay motivo para suponer que el próximo rincón inadvertido del kernel se encontrará más rápido, por lo que reducir lo que realmente es alcanzable en una máquina dada importa con independencia de cualquier fecha de parche concreta.

Acceso root y escape de contenedores, demostrados

El Zhuque Lab de Tencent demostró el exploit de principio a fin, no solo un fallo puntual. En sistemas con Debian 13, Ubuntu 24.04, Rocky Linux 9, RHEL 9 y OpenCloudOS, el equipo convirtió el use-after-free en una escalada completa de privilegios a root desde una cuenta local sin privilegios, y después usó la misma técnica para escapar de un contenedor hacia el host en seis de ocho intentos, sin necesitar CAP_NET_ADMIN ni CAP_SYS_ADMIN, las capacidades elevadas que la mayoría de las guías de blindaje de contenedores dan por requisito previo del atacante.

La cadena de explotación burló la aleatorización del espacio de direcciones del kernel, encadenó un segundo use-after-free usando claves de autenticación SCTP controladas por el atacante, y construyó un grafo de objetos de kernel falsificado para alcanzar root, todo sin shellcode ni una cadena de programación orientada al retorno, las técnicas que la mayoría de las mitigaciones de exploits de kernel están diseñadas para detectar. Las pruebas abarcaron versiones de kernel desde la 5.14 hasta el candidato de lanzamiento 7.2, y la corrección upstream llegó como el commit 9b2854f86f0b antes de ser retroportada a las cuatro ramas estables mencionadas.

La corrección sencilla que la mayoría de equipos se salta

El parche es real y merece aplicarse, pero trata un síntoma. Casi ninguna de las organizaciones que operan estas cinco distribuciones eligió activar SCTP - viene compilado por defecto en el kernel principal, y la mayoría de los operadores no tiene ni idea de que está ahí, y mucho menos de que un proceso local puede alcanzarlo. Esa es la lección real escondida en el propio hilo de divulgación de oss-security de los investigadores: un participante en el hilo señaló que los sistemas de la familia RHEL mantienen SCTP fuera por defecto, distribuido como paquete aparte kernel-modules-extra con la carga automática bloqueada, mientras que los kernels de la familia Debian y Ubuntu integran SCTP directamente y lo dejan cargarse en cuanto cualquier proceso lo solicita. Dos sistemas pueden compartir la misma CVE y tener un riesgo real muy distinto, y la diferencia no tiene nada que ver con qué parche esté instalado.

La medida que merece la pena tomar esta semana no es esperar a la actualización de la distribución, sino comprobar si SCTP hace algo útil en una flota dada. Ejecutar lsmod | grep sctp muestra si el módulo está cargado actualmente; revisar /etc/modprobe.d/ en busca de una entrada de bloqueo existente muestra si la carga automática ya está impedida. Donde nada depende legítimamente de SCTP - y en la mayoría de los servidores de propósito general no depende nada - bloquear el módulo cierra la puerta con independencia de qué versión de kernel llegue más adelante, un hábito que coincide con lo que el INCIBE español y la mayoría de las guías nacionales de blindaje ya recomiendan para cualquier módulo de kernel sin usar, no solo para este.

Leer a continuación: Su MSP tiene una segunda brecha de bypass  |  La llamada que burla el MFA de su empresa