Containers Are No Longer a Security Boundary

TL;DR: Containers are generally considered as a robust security isolation boundary and are widely used to isolate workloads across enterprise and cloud environments. As AI accelerates kernel vulnerability discovery and exploitation, the barrier to escaping containers by attacking kernel has fallen so significantly that we must assume attackers can do so at will. There are nearly 6000 kernel CVEs published as of September 2026. In this post, we demonstrate such a case using CVE-2026-80521, a Linux kernel use-after-free vulnerability in the AF_UNIX subsystem discovered with dfs-large1. The exploit code is available on GitHub. Organizations should move sensitive and untrusted workloads to stronger isolation technologies such as Firecracker or Kata Containers.

On July 24, 2026, we won a Google kernelCTF slot with a zero-day exploit for CVE-2026-80521. The vulnerability is a heap use-after-free in Linux kernel’s AF_UNIX subsystem, discovered using dfs-large1, our in house AI model trained for vulnerability detection, combined with our harness.

The AF_UNIX subsystem is the foundation of local inter-process communication (IPC) in the Linux kernel. If you have ever used a local socket, connected to a local database, or relied on system services like systemd or Docker, you have interacted with the subsystem. It provides the AF_UNIX socket family, which allows processes on the same machine to exchange data and, crucially, pass file descriptors to one another using SCM_RIGHTS messages. The vulnerability we discovered, CVE-2026-80521, resides in the garbage collection mechanism responsible for cleaning up these AF_UNIX sockets. Specifically, a race condition during the garbage collection of SCM_RIGHTS messages leads to a struct unix_vertex use-after-free. Because it handles these fundamental operations, it is deeply integrated into the kernel’s core architecture. The vulnerability here could impact most of the OS-level sandboxes (e.g., nsjail, Firejail, and Bubblewrap) and isolation mechanisms built on top of the kernel, including modern container runtimes.

For years, people have treated containers as a robust isolation boundary. In the cybersecurity community, for example, many Capture The Flag organizers host different challenges within the same server isolated by container, trusting that the host machine remains secure. In the enterprise world, this trust scales up to massive Kubernetes (K8s) deployments. Modern microservice-based applications run dozens to thousands of services, using Kubernetes pods as the basic unit of scheduling and containment. Modern cloud infrastructure is built heavily on multi tenancy, where workloads from different teams, or even entirely different organizations, run side by side on the same physical nodes. The container is treated as a hard security perimeter, almost like a lightweight virtual machine.

By design, containers drastically reduce the attack surface available to an adversary. When running workload in Docker or a Kubernetes pod, the runtime applies multiple layers of defense. Linux namespaces (like pid, net, and mnt) ensure the containerized process cannot see or interact with resources outside its isolated environment. Control groups (cgroups) restrict resource usage to prevent denial-of-service attacks. Crucially, runtimes apply strict seccomp-bpf profiles that filter which system calls the container can make to the kernel, blocking access to obscure or dangerous kernel APIs. Because of this high barrier to entry, the container threat model was generally perceived robust.

Despite all these defenses, containers still share a single, monolithic kernel with the host OS. While a container packages its own user-space binaries, libraries, and application code, it does not bring its own operating system. Every container on a node relies on the host’s kernel to manage memory, schedule CPU time, route network packets, and handle inter-process communication like the UNIX subsystem. If an attacker can find a vulnerability in a kernel subsystem that is reachable from within the container, they can achieve a container escape. By exploiting the kernel directly, the attacker elevates their privileges to kernel level, completely bypassing all user-space isolation mechanisms. From there, they can pivot to the host machine, access other containers, and compromise the entire Kubernetes node in enterprise production environment.

Historically, only the most sophisticated attackers could find these bugs and master the complex exploitation techniques required to weaponize them. With the advancement of AI, the Linux kernel’s security landscape has changed completely. In 2026 alone, there have been 5,976 unique Linux kernel CVEs published (as of mid-September). The escalation is staggering: while January saw around 250 CVEs, August peaked at 1,650 published vulnerabilities, accounting for over 27% of the year’s total in a single month. To understand the severity of this trend for container security, let’s look at the data from Google’s kernelCTF. Out of the 36 distinct CVEs publicly disclosed there, 13 of them are reachable from ordinary, unprivileged interfaces, targeting the fundamental, everyday subsystems that are exposed to containers by default, including epoll, futex, POSIX timers, and AF_UNIX sockets.

With frontier AI models now capable of one-shotting exploit generation, attackers with little resource can easily develop 1-day exploits for these unpatched systems the moment a bug is disclosed. Furthermore, The sheer volume of new vulnerabilities is also overwhelming the ecosystem. As thousands of CVEs being reported, major Linux distributions are lagging significantly in backporting patches. There is a massive backlog of unpatched bugs in production systems, and we have no idea what new zero-days will be disclosed tomorrow. CVE-2026-80521, one of the AF_UNIX vulnerabilities discovered this year, is an example of this new reality. As of today, it is still unpatched in the latest ubuntu 26.04 release.

CVE-2026-80521

The vulnerability resides in the AF_UNIX garbage collection (GC) mechanism, specifically within how it handles SCM_RIGHTS messages. When you pass file descriptors over a UNIX socket, the kernel must ensure that circular references (e.g., socket A holds a reference to socket B, and socket B holds a reference to socket A) are eventually cleaned up. To do this, the GC represents each socket with in-flight references as a struct unix_vertex, and creates a struct unix_edge pointing to the receiving socket.

To optimize subsequent GC passes, the kernel groups strongly connected components (SCCs) and caches them in a persistent scc_entry ring. However, two specific behaviors in the kernel combine to leave a freed vertex inside this persistent ring, resulting in a classic Use-After-Free.

1. Edges are visible before the SKB is queued

When sending a message, the kernel publishes the SCM graph edges before it actually queues the socket buffer (skb) that carries the references:

maybe_add_creds(skb, sock, other);
scm_stat_add(other, skb); // Calls unix_add_edges(), making edges visible to GC
spin_lock(&other->sk_receive_queue.lock);
__skb_queue_tail(&other->sk_receive_queue, skb);
spin_unlock(&other->sk_receive_queue.lock);

Because unix_add_edges() temporarily takes and releases the unix_gc_lock, the garbage collector can interrupt the send path and observe the new edges before the skb is safely on the queue. If the GC decides the SCC is dead, it can collect older queued messages but cannot collect this new off-queue skb.

2. GC frees a vertex without unlinking scc_entry

When the GC purges a collected SCM message, it calls unix_del_edge(). If this removes the last edge from a vertex (bringing its out-degree to zero), the vertex is moved to a private list and subsequently freed by unix_free_vertices().

static void unix_del_edge(struct scm_fp_list *fpl, struct unix_edge *edge)
{
        struct unix_vertex *vertex = edge->predecessor->vertex;
        // ...
        list_del(&edge->vertex_entry);
        vertex->out_degree--;

        if (!vertex->out_degree) {
                edge->predecessor->vertex = NULL;
                list_move_tail(&vertex->entry, &fpl->vertices); // Vertex moved to be freed
        }
}

The fatal flaw is that nothing removes the vertex from its persistent scc_entry ring before it is freed. If another socket in the same SCC survives (which is possible due to the off-queue skb mentioned above), that surviving socket’s scc_entry ring will still contain a pointer to the freed vertex. When the next GC pass occurs, it walks this stale ring via unix_walk_scc_fast(), dereferencing the freed memory and triggering the Use-After-Free (UAF).

We have released our complete container escape exploit for CVE-2026-80521 here, which successfully targets the latest Ubuntu 26.04. Additionally, we add an exploit for CVE-2026-52910, demonstrating a escape against the latest Ubuntu 24.04.

Mitigation

Containers are not a safe security boundary anymore. The industry’s long standing reliance on Linux kernel as an strong security boundary has been completely dismantled by the rapid advancement of AI. As models from the frontier labs, as well as dfs-large1, continue to scale, researchers will inevitably uncover a continuous stream of deep, logical kernel flaws that bypass traditional userspace sandboxing. The barrier to entry for weaponizing these vulnerabilities has dropped so significantly that we must assume attackers already have the capability to escape standard containers at will. This is no longer a theoretical threat, it echoes to the recent OpenAI Hugging face incident that how AI can easily find and exploit zero-days now. Think about attackers with the most accessible AI models are capable of escaping containers to move laterally across networks, the traditional threat model is dead.

To protect multi-tenant environments, and critical cloud workloads, the industry must pivot away from the shared kernel architectures and adopt stronger isolation. We strongly recommend migrating untrusted workloads to microVMs. Technologies like Firecracker or Kata Containers provide a much smaller attack surface. By giving each workload its own isolated, lightweight kernel, microVMs ensure that even if an attacker successfully exploits a kernel zero-day, they only compromise their own ephemeral instance, leaving the host and other tenants secure.

The era of trusting the monolithic kernel is over, it is time to build infrastructure that assumes the kernel will be breached at attackers’ will.

Timeline of CVE-2026-80521

7/24/2026 - We exploited the KernelCTF target and submitted our flag.
8/5/2026 - We got confirmation of winning the lts-6.12.95 slot.
8/5/2026 - We reported the findings to security@kernel.org.
8/5/2026 - We got reply that the same bug was reported by Kyle from OpenAI.
8/6/2026 - The patch to this vulnerability is released upstream.
9/22/2026 - We published our research.