Un exploit público de AF_UNIX rompe el aislamiento de los contenedores Ubuntu y obtiene acceso root al host

Un exploit público para CVE-2026-80521 puede convertir la ejecución limitada de código dentro de un contenedor Ubuntu en privilegios root en el host subyacente.

La vulnerabilidad es un use-after-free en el recolector de basura de sockets AF_UNIX del kernel de Linux. Se puede activar mediante llamadas al sistema habituales permitidas por las configuraciones estándar de seccomp de Docker y Kubernetes, por lo que los controles predeterminados de los contenedores resultan ineficaces frente a esta vía de ataque.

DepthFirst publicó código de exploit funcional dirigido a Ubuntu 26.04. A fecha de 23 de septiembre de 2026, no se ha confirmado ningún ataque y la vulnerabilidad no figura en el catálogo de vulnerabilidades explotadas conocidas de la Agencia de Ciberseguridad y Seguridad de las Infraestructuras de Estados Unidos (CISA). Por tanto, no existe una fecha límite de corrección establecida por CISA.

No obstante, la publicación del exploit eleva el riesgo para las plataformas que ejecutan contenedores no confiables o parcialmente confiables sobre un kernel compartido.

Una condición de carrera en la recolección de basura de AF_UNIX crea la vía de escape

Los sockets AF_UNIX permiten la comunicación local entre procesos y pueden transferir descriptores de archivo abiertos mediante mensajes SCM_RIGHTS. El kernel debe realizar un seguimiento de esas referencias transferidas y recuperar los grupos circulares de sockets que ya no son accesibles.

CVE-2026-80521 se origina en una condición de carrera dentro de ese proceso de recolección de basura.

Ubuntu atribuye el informe a Kyle Zeng. Su descripción técnica utiliza tres sockets —A, B y X— para explicar cómo se desarrolla la condición de carrera:

1. Los sockets A y B pertenecen a grupos de referencias enlazados, conocidos como componentes fuertemente conexos o SCC, mientras que X está asociado al grupo.
2. Varias operaciones simultáneas envían sk-B desde sk-X a sk-B y cierran A y B.
3. Durante la operación de envío, unix_add_edges() publica una nueva arista que representa la relación de B consigo mismo.
4. Existe un intervalo muy breve antes de que el búfer de socket que contiene esa referencia se inserte mediante skb_queue_tail().
5. Si las operaciones de cierre y la recolección de basura tienen lugar durante ese intervalo, el recolector puede clasificar el grupo A-B como muerto.
6. B no se libera de inmediato porque el recolector todavía no puede ver el búfer de socket que contiene la referencia recién publicada.
7. Una pasada posterior del recolector sigue el scc_entry obsoleto de B hasta un estado parcialmente liberado.

El resultado es un use-after-free. La corrección incorporada en el código upstream, titulada af_unix: Unlink scc_entry in unix_del_edge()., elimina la entrada SCC interna antes de liberar el vértice asociado.

La explicación de DepthFirst llega a la misma conclusión fundamental: el recolector puede observar una referencia publicada antes de ver la estructura de datos que la contiene. La limpieza parcial deja entonces un puntero persistente que apunta a memoria ya liberada.

Los controles predeterminados de los contenedores no bloquean las llamadas necesarias

La vulnerabilidad no requiere acceso remoto al host. El atacante necesita un contexto de ejecución local con pocos privilegios, como el control de un proceso dentro de un contenedor.

Este requisito se refleja en la puntuación CVSS alta de 7,8 y en el siguiente vector:

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

El ataque tiene una complejidad baja, requiere pocos privilegios y no necesita interacción del usuario. Una explotación satisfactoria puede comprometer la confidencialidad, la integridad y la disponibilidad del host.

Las operaciones de sockets AF_UNIX suelen estar disponibles dentro de los contenedores. Los perfiles de seccomp de Docker y Kubernetes permiten de forma predeterminada las interfaces pertinentes, por lo que el exploit no depende de una configuración inusual o deliberadamente permisiva.

Una vez explotado el fallo de memoria del kernel, los espacios de nombres, los cgroups y los filtros de seccomp no pueden preservar el límite de seguridad previsto. Estos mecanismos aíslan los procesos, pero dependen del mismo kernel del host. Un compromiso del kernel opera por debajo de ellos.

Esta distinción es importante para los servicios multiinquilino, los ejecutores de CI/CD, los entornos de desarrollo basados en contenedores y los sistemas que ejecutan código enviado por clientes. Un proceso que debería estar confinado a un solo contenedor puede obtener en su lugar control root sobre el host y afectar potencialmente a otras cargas de trabajo que lo compartan.

La exposición de Ubuntu depende del paquete de kernel instalado

El rastreador de seguridad a nivel de paquete de Ubuntu ofrece una evaluación más precisa que el número de versión del sistema operativo por sí solo.

El paquete base linux de Ubuntu 22.04 LTS figura como no afectado. Sin embargo, el paquete linux-hwe-6.8 de esa misma versión es vulnerable. Por tanto, los administradores deben comprobar la variante del kernel y la rama de paquetes que están instaladas realmente.

Los estados publicados pertinentes son:

Paquete	Versión de Ubuntu	Estado
linux	26.04 LTS, Resolute	Vulnerable, corrección en curso
linux	24.04 LTS, Noble	Vulnerable
linux	22.04 LTS, Jammy	No afectado
linux-hwe-6.8	22.04 LTS, Jammy	Vulnerable
linux-hwe-6.17	24.04 LTS, Noble	Vulnerable
linux-hwe-7.0	24.04 LTS, Noble	Vulnerable
linux-aws	26.04 LTS, Resolute	Vulnerable
linux-aws	24.04 LTS, Noble	Vulnerable
linux-aws	22.04 LTS, Jammy	No afectado
linux-aws-6.8	22.04 LTS, Jammy	Vulnerable
linux-aws-7.0	26.04 LTS, Resolute	Vulnerable
linux-azure	26.04 LTS, Resolute	Vulnerable
linux-azure	24.04 LTS, Noble	Vulnerable
linux-azure	22.04 LTS, Jammy	No afectado
linux-azure-6.8	22.04 LTS, Jammy	Vulnerable

Varias ramas antiguas o sustituidas figuran como no afectadas, no incluidas en la versión, ignoradas o fuera de mantenimiento. Entre ellas se encuentran linux-kvm en Ubuntu 22.04, 20.04 y 18.04, además de las ramas AWS, Azure y HWE 5.15 de Ubuntu 20.04.

El aviso de Ubuntu disponible no proporciona el estado de ningún paquete específico para GCP. Tampoco ofrece una fecha para las compilaciones corregidas de Ubuntu.

Existe un parche upstream, pero la corrección de Ubuntu sigue incompleta

El código vulnerable del kernel se introdujo en Linux 6.10 y se trasladó posteriormente a las ramas estables 6.1 y 6.6.

La corrección upstream se incorporó el 6 de agosto a la rama principal del kernel 7.2 y al kernel estable 7.1.10. Las organizaciones que mantienen kernels personalizados pueden aplicar directamente ese cambio, siguiendo sus procesos habituales de pruebas y despliegue.

Que la corrección esté disponible upstream no significa que todas las ramas del kernel de Ubuntu hayan recibido un paquete corregido. Ubuntu todavía identifica varias ramas como vulnerables y marca específicamente el paquete base linux de Ubuntu 26.04 como pendiente de corrección.

Ubuntu y DepthFirst no han publicado ninguna medida de mitigación temporal. Tampoco se han divulgado firmas del exploit, artefactos forenses ni indicadores fiables a nivel del kernel que los equipos defensivos puedan utilizar para identificar intentos de explotación.

La investigación asistida por IA produjo un exploit funcional del kernel

DepthFirst afirmó que su modelo de detección de vulnerabilidades, dfs-large1, identificó el fallo con el apoyo de un sistema de pruebas operado por personal humano. La empresa utilizó el exploit para ganar una plaza en Google kernelCTF el 24 de julio e informó del problema al equipo de seguridad del kernel el 5 de agosto.

Posteriormente, los mantenedores del kernel comunicaron a DepthFirst que un investigador de OpenAI había encontrado el mismo fallo de forma independiente. El commit de CVE atribuye el hallazgo a Kyle Zeng.

El episodio demuestra algo más que un proceso automatizado de clasificación de fallos. La investigación condujo a un escape funcional de contenedor contra Ubuntu 26.04, cubriendo el descubrimiento, el análisis de la condición de carrera, la explotación y la validación frente a un objetivo práctico.

También se suma a otras vulnerabilidades del kernel relacionadas con investigaciones asistidas por IA y con la escalada hasta root en el host. La disponibilidad pública de exploits se ha convertido en un problema operativo recurrente para los hosts Linux sin parches, y no solo en una medida de la gravedad teórica.

Los equipos defensivos deben priorizar el inventario del kernel y un aislamiento más sólido

Los administradores deben empezar por asociar cada host de contenedores con el paquete y la rama del kernel instalados. Comprobar únicamente si una máquina ejecuta Ubuntu 22.04, 24.04 o 26.04 no es suficiente, ya que los paquetes base, HWE, AWS y Azure tienen estados diferentes.

Siempre que sea posible, los kernels personalizados afectados deben recibir la corrección upstream. En los sistemas gestionados por Ubuntu, deben instalarse los paquetes corregidos de la distribución en cuanto estén disponibles.

Hasta entonces, las organizaciones deberían reconsiderar qué cargas de trabajo pueden compartir un kernel. DepthFirst recomienda utilizar un aislamiento basado en microVM, como Firecracker o Kata Containers, para el código no confiable. Estos diseños proporcionan kernels independientes a las cargas de trabajo y evitan que un exploit del kernel del contenedor comprometa directamente el kernel principal del host.

La monitorización debe centrarse en procesos inesperados a nivel del host que se originen en contextos de contenedor, transiciones de privilegios no explicadas y cambios no autorizados en archivos del host o en la configuración del runtime. Son señales de alerta basadas en el comportamiento, no indicadores específicos de esta vulnerabilidad.

La ausencia de ataques confirmados o de una inclusión en CISA KEV no debe interpretarse como una baja facilidad de explotación. El código funcional ya es público y las interfaces afectadas están expuestas en las configuraciones estándar de los contenedores.