Si administras sistemas Linux con el protocolo SCTP habilitado, conviene que actúes con rapidez. La vulnerabilidad CVE-2026-64564 SCTP se ha descrito como un use-after-free en el código de red de Linux: en determinadas condiciones, un usuario local podría alcanzar privilegios de administrador en el host y, según pruebas publicadas, incluso salir de un contenedor.
La buena noticia es que la corrección ya se distribuyó en kernels estables recientes. Aun así, la exposición real depende de tu versión exacta, de cómo tu distribución respalda las actualizaciones y de si tienes SCTP accesible desde el entorno donde se originaría el ataque.
Qué es la vulnerabilidad CVE-2026-64564 SCTP
El problema se origina en el manejo de mensajes y rutas dentro de SCTP. SCTP es un protocolo de transporte que permite que una única conexión use varios caminos de red a la vez. Además, incluye una función para reconfigurar direcciones dinámicamente durante la misma conexión, agregando o eliminando direcciones según corresponda.
En CVE-2026-64564 SCTP se produce una confusión de identidad entre lo que el kernel verifica y lo que termina usando. En términos prácticos, el kernel compara una solicitud de borrado contra una dirección, pero después actúa sobre un camino que selecciona usando otra dirección contenida dentro del mensaje. Esa secuencia puede liberar una estructura interna y reutilizar un puntero ya liberado, dejando la conexión apuntando a memoria que el kernel ya descartó.
De acuerdo con la asesoría del kernel, un mismo mensaje puede incluir una dirección, un borrado para esa dirección y, posteriormente, un borrado comodín (wildcard). Con esa combinación es posible desencadenar el patrón de uso de memoria liberada.
Impacto: escalada local y posible escape de contenedores
Este fallo se considera local, no remoto. Eso significa que para que el riesgo exista deben cumplirse condiciones alrededor del acceso: debe haber un usuario o proceso con capacidad de interactuar con SCTP en el objetivo. La exposición es, por tanto, menor que la de una vulnerabilidad explotable desde la red sin más, pero no por ello es despreciable.
Un equipo de investigación (Tencent Zhuque Lab) informó que, cuando esas condiciones se cumplían, lograron obtener privilegios de root en kernels específicos que probaron. También afirman que pudieron escapar de un contenedor y alcanzar la máquina subyacente.
La validación pública externa no estaba confirmada en el momento en que se revisó la información: el informe disponible no aportaba un exploit público, y no se reportaba una entrada en catálogos de “explotadas en la naturaleza” al momento de la consulta mencionada en la fuente.
El error lleva tiempo en el kernel
Una característica importante de CVE-2026-64564 SCTP es su antigüedad. La raíz del comportamiento problemático se remonta a Linux 2.6.25, de acuerdo con el rastreo citado. En otras palabras, el fallo habría estado presente durante años en distintas ramas del kernel.
La vulnerabilidad se registró como CVE-2026-64564 y se conoció con el nombre SCTPhantom por quienes la identificaron. La divulgación pública se produjo poco después de que el equipo asignara el identificador CVE.
Cómo afectarte depende de tu kernel y tu distribución
La corrección ya se publicó en versiones estables. En el resumen que se compartió, se indicaron como versiones con el fix las siguientes: 7.1.6, 6.18.42, 6.12.101 y 6.6.148. También se mencionó que la corrección se entrega en esas ramas mediante releases estables el 3 de agosto.
Si tu sistema usa un kernel más antiguo, y SCTP es alcanzable, la recomendación es actualizar. Ahora bien, hay un matiz: en entornos reales los proveedores a veces aplican “backports” del parche sin que cambie el número de versión del kernel que ve el usuario. Por eso, no basta con comprobar solo el string de versión; es esencial revisar el rastreador o el boletín de tu distribución para saber si el fix está incluido.
Además, se mencionó que existe otro fallo relacionado de tipo dangling-transport use-after-free en el mismo componente, corregido el 6 de agosto después de que salieran los releases estables de 3 de agosto. Esto implica que no todas las versiones “cercanas” necesariamente cubren ambos problemas.
Condiciones técnicas: SCTP accesible y reconfiguración dinámica
En el informe de pruebas, el equipo de investigación describe que el exploit inicial requería que se habilitaran ciertos parámetros del sistema SCTP: net.sctp.addip_enable y net.sctp.addip_noauth_enable. Eso, según su interpretación, hacía que CAP_NET_ADMIN pareciera un requisito.
Más adelante, indicaron que hallaron una ruta alternativa en la que pueden evitarse esos ajustes globales activando las funciones a nivel de socket. Con esa evolución, el rol de CAP_NET_ADMIN deja de ser el factor determinante en su secuencia de pruebas.
También afirman que sus intentos de escape se realizaron manteniendo el perfil seccomp por defecto y sin conceder CAP_NET_ADMIN ni CAP_SYS_ADMIN dentro del contenedor. En su conteo, 6 de 8 intentos llegarían a root en el host.
Como siempre, estos resultados reflejan el escenario evaluado por ese laboratorio. La exposición puede cambiar cuando se modifican perfiles seccomp, políticas de user-namespace u otras configuraciones que redistribuyen el riesgo hacia otros controles.
Mitigaciones prácticas si necesitas reducir el riesgo
Hay varias acciones que puedes aplicar, incluso si no puedes actualizar de inmediato.
- Actualiza el kernel a una versión estable que incluya el fix (o confirma el backport en tu distribución).
- Verifica si SCTP es necesario en tu entorno. Si no lo utilizas, bloquear o deshabilitar el módulo puede eliminar la superficie de ataque relacionada con SCTP.
- Revisa el acceso: al tratarse de una falla local, controla qué usuarios o servicios pueden interactuar con SCTP en el host o en el contenedor.
- Refuerza capas de contención (seccomp, políticas de espacios de nombres, permisos y capacidades) para reducir el impacto potencial si se explotara la falla.
Si tu objetivo es cumplir buenas prácticas de seguridad, el camino más sólido sigue siendo aplicar el parche. Las mitigaciones ayudan a ganar tiempo, pero no sustituyen el update.
Estado del riesgo y puntuación
La severidad exacta no estaba completamente cerrada en la información revisada. El laboratorio que reportó el problema asignó una puntuación de 8.5 según CVSS v4.0. En la consulta referida, el NVD no había publicado todavía una puntuación ni una clasificación de debilidad.
Además, se mencionó que otros asesoramientos públicos relacionados con el mismo bug se limitaban a describir efectos como kernel panic o denegación de servicio, sin extenderse a los mismos escenarios de privilegios o escape.
Por qué importa ahora: más vulnerabilidades “dormidas” con ayuda automatizada
El informe atribuye el hallazgo a un pipeline de investigación multiagente de Tencent para trabajo con kernels. En el texto fuente también se contextualizó este hallazgo como parte de una serie de vulnerabilidades previamente dormidas que emergen con asistencia automatizada, incluyendo otro caso de julio mencionado como GhostLock.
La coincidencia temporal también se destacó con un anuncio de Zapscape, una vulnerabilidad distinta relacionada con escape en KVM. Aunque son problemas diferentes, refuerzan la idea de revisar actualizaciones de seguridad de forma continua.
Conclusión: actualiza y confirma el parche
CVE-2026-64564 SCTP es una vulnerabilidad relevante para quienes usan SCTP en Linux, porque combina un error de memoria (use-after-free) con condiciones que permiten impacto local. Según las pruebas publicadas, podría facilitar escalada de privilegios y, en algunos escenarios, escape de contenedores.
La corrección ya está disponible en releases estables concretos, y la recomendación principal es clara: actualiza tu kernel o verifica que tu distribución haya incorporado el parche mediante backports. Si SCTP no es imprescindible, deshabilitarlo también reduce el riesgo. Con estas medidas, puedes proteger tu infraestructura antes de que el problema se convierta en una amenaza operativa.
Fuente: https://thehackernews.com/2026/08/18-year-old-linux-sctp-flaw-could-let.html
