Introducción
Un equipo de SRE despliega un microservicio en un pod de Kubernetes con seccomp en modo RuntimeDefault, cgroups limitados y namespaces de red y PID aislados. El pod no tiene privilegios, no accede al filesystem del host y la superficie de syscalls está filtrada. Aun así, un exploit publicado el 22 de septiembre por DepthFirst logra ejecutar código como uid 0 en el nodo subyacente. La vía es un use-after-free en el garbage collector de sockets AF_UNIX (CVE-2026-80521, CVSS 7.8), una primitiva que Docker y Kubernetes habilitan por defecto en sus perfiles seccomp. Ubuntu 26.04, 24.04 y 22.04 LTS siguen sin parche a fecha de publicación.
El problema no es hipotético: DepthFirst liberó código de explotación funcional contra Ubuntu 26.04 y lo validó en el kernelCTF de Google el 24 de julio. La corrección upstream existe desde el 6 de agosto en mainline 7.2 y stable 7.1.10, pero Canonical mantiene el paquete linux como «vulnerable, work in progress» sin fecha estimada de publicación.
Qué ocurrió
El bug vive en el recolector de basura que gestiona los file descriptors pasados entre procesos mediante mensajes SCM_RIGHTS sobre sockets AF_UNIX. Cuando un proceso envía un fd a otro, el kernel encola una referencia en una lista interna de sockets enlazados. El garbage collector recorre esa lista para liberar referencias huérfanas. La race condition aparece en una ventana estrecha: el GC puede observar una referencia nueva antes de que los datos que la transportan hayan sido efectivamente encolados. Si el recolector se ejecuta en ese intervalo, libera parte del grupo de sockets enlazados pero deja un puntero colgante en la lista persistente. La siguiente pasada del GC sigue ese puntero hacia memoria ya devuelta al allocator del kernel, habilitando la escritura controlada que DepthFirst convirtió en escalada a root.
La primitiva llega al kernel a través de syscalls ordinarias (socket, bind, sendmsg con SCM_RIGHTS) que los perfiles seccomp estándar de Docker y Kubernetes permiten sin restricciones adicionales. Esto significa que el exploit no necesita CAP_SYS_ADMIN, no requiere acceso a /proc ni a dispositivos del host, y no depende de configuraciones exóticas. Funciona en un pod con defaults.
Impacto para DevOps / Infraestructura / Cloud / Seguridad
El alcance es amplio porque la superficie expuesta es omnipresente en stacks de contenedores. Docker permite AF_UNIX por defecto en su perfil seccomp; Kubernetes hereda ese comportamiento en RuntimeDefault. Cualquier workload que comparta kernel con el nodo —sin importar si corre en EKS, AKS, GKE o un cluster on-premises con k3s— está expuesto mientras el kernel del host sea vulnerable.
Los kernels afectados incluyen 6.10 (donde se introdujo el código defectuoso) y los backports a las ramas stable 6.1 y 6.6. Ubuntu distribuye kernels basados en esas líneas en 22.04 (jammy, kernel 6.8 HWE), 24.04 (noble, 6.8) y 26.04 (resolute, 6.14+). Las imágenes de AWS (Amazon Linux 2023), Azure (CBL-Mariner / Ubuntu) y GCP (Container-Optimized OS) también heredan kernels en el rango vulnerable si no aplicaron el parche de agosto. Aun así, no hay reportes confirmados de explotación en el mundo real y la CVE no figura en el catálogo KEV de CISA.
El CVSS 7.8 refleja un ataque local con baja complejidad y sin privilegios previos, pero sin impacto directo en confidencialidad/integridad/availabilidad del servicio de red. En un nodo Kubernetes, sin embargo, el impacto real es la toma del host completo: acceso a secrets montados en pods vecinos, credenciales del kubelet, datos en volúmenes persistentes y la capacidad de moverse lateralmente por la red del cluster.
Detalles técnicos
Componente afectado: net/unix/garbage.c en el subsistema AF_UNIX del kernel Linux.
Versión donde se introdujo el defecto: kernel 6.10. Backport a stable 6.1.y y 6.6.y.
Parche upstream: commit en mainline kernel 7.2 y rama stable 7.1.10, publicado el 6 de agosto de 2026.
Mecanismo de ataque: race condition en unix_gc(). El recolector lee una referencia nueva en la lista unix_socket_gc_list antes de que el sk_buff que la contiene haya completado el encolado vía unix_scm_add_to_scm_send_queue. El GC libera el unix_sock asociado, pero el puntero queda en la lista. La siguiente pasada dereferencia memoria freed. El exploit de DepthFirst explota esa primitiva UAF para corromper un cred struct en memoria del kernel y obtener uid 0.
Requisitos desde el contenedor: syscalls socket(AF_UNIX, SOCK_STREAM), bind(), sendmsg() con SCM_RIGHTS. Todas permitidas en perfiles seccomp RuntimeDefault de Kubernetes y en el perfil default de Docker.
Mitigaciones parciales sin parche: ninguna publicada por Ubuntu ni por DepthFirst. Restrictir AF_UNIX en seccomp es posible pero rompe comunicación IPC local que muchos workloads necesitan (systemd-resolved, dbus, sockets de health-check).
Volumen contextual: LinuxCVETracker registra casi 5.700 CVEs de kernel en 2026, el máximo anual histórico. El descubrimiento de DepthFirst usó su modelo dfs-large1 entrenado para detección de vulnerabilidades, junto con un harness de testing humano. Un investigador de OpenAI reportó el mismo bug de forma independiente.
Qué deberían hacer los administradores y equipos técnicos
Verificar la versión del kernel en todos los nodos:
# En cada nodo del cluster
uname -r
# o para detalle del paquete
dpkg-query -W linux-image-generic 2>/dev/null || rpm -q kernel
Si el kernel está en 6.10.x, 6.1.y posterior al backport defectuoso, o 6.6.y con backport, está expuesto.
Aplicar el parche upstream directamente si el paquete de distro no está disponible:
# Clonar el kernel con el fix (rama stable 7.1.10 o mainline 7.2)
git clone https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
cd linux && git checkout v7.1.10
# Aplicar solo el commit de net/unix/garbage.c si no querés recompilar todo
# Compilar e instalar el módulo afectado
make -j$(nproc) M=net/unix modules
sudo cp net/unix/unix.ko /lib/modules/$(uname -r)/kernel/net/unix/
sudo depmod -a && sudo modprobe -r unix && sudo modprobe unix
Esto es una workaround para entornos donde la recompilación completa del kernel no es viable en el corto plazo. Para producción, la recomendación es aplicar el parche en el build completo y reiniciar.
Si no podés parchear inmediatamente, reducir la superficie:
# En Kubernetes, reemplazar RuntimeDefault por un perfil que bloquee AF_UNIX
# (evaluar impacto en workloads que usan IPC local)
securityContext:
seccompProfile:
type: Localhost
localhostProfile: no-af-unix.json
// no-af-unix.json (fragmento)
{
«defaultAction»: «SCMP_ACT_ERRNO»,
«syscalls»: [
{
«names»: [«socket»],
«action»: «SCMP_ACT_ALLOW»,
«args»: [
{
«index»: 0,
«value»: 1,
«op»: «SCMP_CMP_NE»
}
]
}
]
}
Esto bloquea socket(AF_UNIX=1, …) pero mantiene AF_INET y AF_INET6. Validá que tus workloads no dependan de sockets de dominio UNIX antes de aplicar.
Para workloads de terceros o multi-tenant, migrar a microVM: DepthFirst y Red Hat recomiendan Firecracker (AWS Lambda) o Kata Containers. Cada pod obtiene un kernel propio, eliminando la superficie compartida. En EKS, esto es nativo con amazon-vpc-cni + Firecracker; en GKE, con gVisor (runsc) como runtime handler.
Monitorear el tracker de Ubuntu y los canales de las nubes:
# Ubuntu 26.04
apt-cache policy linux-image-generic
# Verificar si Canonical publicó el kernel con el fix
# Suscribir al RSS de ubuntu-security-announce
En AWS, revisar el advisory de AL2023; en Azure, el changelog de CBL-Mariner; en GCP, el release notes de COS. Ninguno garantizó fecha de parche a la publicación de este artículo.
Conclusión
CVE-2026-80521 no es el primer escape de contenedor de 2026 —julio trajo uno en futex y abril otro en el subsistema criptográfico— pero refuerza una tendencia incómoda: la separación por namespaces y cgroups no es una frontera de seguridad cuando el kernel compartido contiene una primitiva de UAF alcanzable desde syscalls permitidas. Con 5.700 CVEs de kernel este año y herramientas de descubrimiento asistido por IA reduciendo el tiempo entre hallazgo y exploit funcional, tratar al contenedor como aislamiento de seguridad ya no es una postura defendible en entornos multi-tenant o expuestos a workloads no confiables. El parche existe; la brecha es operativa. Cerrarla requiere priorizar la actualización de kernels del host por encima de la cadencia de releases de la distro, o bien eliminar la dependencia de un kernel compartido mediante microVMs.
Fuentes
- https://thehackernews.com/2026/09/exploit-released-for-unpatched-ubuntu.html
- https://www.redhat.com/en/blog
- https://ai.meta.com/blog/