A Public Exploit Escapes Ubuntu Containers Before the Patch Ships

TL;DR

• On September 22, 2026, security firm DepthFirst published a working container-escape exploit for CVE-2026-80521, a heap use-after-free in the Linux kernel's AF_UNIX socket subsystem, demonstrated against Ubuntu 26.04 LTS.
• The upstream kernel fix landed on August 6, 2026 — seven weeks earlier. As of September 24, Ubuntu's security tracker still lists the main kernel package on 26.04 as "Vulnerable, work in progress" and 24.04 as vulnerable, including AWS, Azure, and GCP kernel variants.
• The vulnerable code is reachable from inside default Docker and Kubernetes containers: AF_UNIX sockets and SCM_RIGHTS descriptor passing are permitted by standard seccomp profiles, so the race bypasses namespace isolation, cgroup limits, and seccomp filtering in one chain.
• No confirmed in-the-wild exploitation and no CISA KEV listing as of publication — but public exploit code plus an unpatched LTS distribution is exactly the combination that stops being academic.
• The disclosure timeline is the story: kernelCTF slot on July 24, disclosure to [email protected] on August 5, upstream fix on August 6, public exploit on September 22 — with Ubuntu's kernel still listed as vulnerable on September 24.
• 5,976 unique Linux kernel CVEs were published between January and mid-September 2026, with August alone peaking at 1,650 — the AI-discovery economics that make public exploits before distribution patches the new normal.
• DepthFirst's recommendation is structural: move untrusted and multi-tenant workloads to microVMs (Firecracker, Kata Containers) that give each workload its own kernel.

The seven-week gap nobody benefits from

The story of CVE-2026-80521 is not the bug; kernel use-after-frees are routine. The story is the timeline. DepthFirst won a Google kernelCTF slot with the zero-day on July 24, reported it to the kernel security team on August 5 — the team replied that Kyle Zeng of OpenAI had independently reported the same bug — and the fix shipped upstream on August 6. Then the exploit sat with a public timeline while the distributions caught up. DepthFirst published the write-up and exploit on September 22. As of September 24, Ubuntu's own tracker says of the main kernel package on Ubuntu 26.04 LTS: "Vulnerable, work in progress." Ubuntu 24.04 LTS is listed as vulnerable, and so are the AWS, Azure, and GCP kernel packages for both releases. A reproduction of the tracker's status is below.

This is precisely the window that public exploit code makes dangerous. There is no confirmed evidence of in-the-wild exploitation yet, and the CVE is not in CISA's Known Exploited Vulnerabilities catalog — but the exploit is on GitHub, targeting the newest LTS, and the fix has been upstream since August 6. Every day the distribution backport lags is a day where a competent operator with no novel skill can run a published exploit against a production host. That is the difference between a theory and an exposure.

A race in the AF_UNIX garbage collector

The bug lives in the kernel's AF_UNIX socket subsystem, the foundation of local inter-process communication on Linux. Every local database connection, systemd socket, and Docker interaction touches it. AF_UNIX sockets let processes pass file descriptors to each other using SCM_RIGHTS messages, and the kernel garbage collector tracks those references to clean up circular dependencies. The flaw is a race inside that collector. When a process sends file descriptors, the kernel publishes the new graph edges before the socket buffer that carries them is queued: scm_stat_add() calls unix_add_edges() to make the edges visible to the collector, then the buffer is queued with __skb_queue_tail() a few instructions later. Because unix_add_edges() takes and releases the unix_gc_lock, the collector can interrupt the send path and see edges whose owning socket buffer is not yet on the queue. If the collector then decides a strongly connected component is dead, it can free part of it — through unix_del_edge() and unix_free_vertices() — without unlinking the vertex from the persistent scc_entry ring. A surviving socket in the same SCC still points into freed memory. The next collection pass walks the stale ring via unix_walk_scc_fast() and dereferences freed memory: a textbook use-after-free whose upstream fix is literally named "af_unix: Unlink scc_entry in unix_del_edge()." The fixed commit is 594d905 in net/unix/garbage.c.

Reachability is the second half of the story. AF_UNIX sockets and SCM_RIGHTS descriptor passing are allowed by default Docker and Kubernetes seccomp profiles — they are ordinary operations inside a standard container. The exploit needs no CAP_SYS_ADMIN, no privileged flag, no kernel module loading, no seccomp modification. It bypasses namespaces, cgroups, and seccomp in a single chain because the corrupted structure is shared kernel state. DepthFirst notes the same subsystem is relied on by nsjail, Firejail, and Bubblewrap, so OS-level sandboxes built on the kernel are exposed too, not just Docker and Kubernetes.

The AI-discovery angle changes the economics

DepthFirst did not find this bug by eyeballing code. It used dfs-large1, an in-house AI model trained for vulnerability detection, combined with a human-operated testing harness — and the company is explicit about what the model means for the threat model: "the barrier to escaping containers by attacking kernel has fallen so significantly that we must assume attackers can do so at will." The escalation figures in the write-up are stark: 5,976 unique Linux kernel CVEs published between January and mid-September 2026, with August alone peaking at 1,650 published vulnerabilities — over 27% of the year's total in a single month. Of the 36 CVEs publicly disclosed through Google's kernelCTF program, 13 are reachable from ordinary, unprivileged interfaces in subsystems exposed to containers by default.

That is the uncomfortable synthesis. Containers share the host kernel by design; the kernel has thousands of published holes per year, many reachable from default container syscalls; and AI-accelerated discovery is compressing the time between "bug exists" and "working exploit published." DepthFirst's own numbers frame the shift: 5,976 unique Linux kernel CVEs published between January and mid-September 2026, August alone peaking at 1,650. The traditional stance — patch the distribution kernel when a USN lands — still works, but it now operates on attacker timescales where public exploit code can precede the distribution fix by weeks. This is exactly the pattern our copy-fail analysis of container security warned about: the host kernel is the real boundary, and a kernel bug is a container-escape bug by definition.

The operational response: microVMs for untrusted workloads

With no distribution fix shipped and no workaround published by either DepthFirst or Canonical, the only structural mitigation is to stop sharing the kernel with workloads you do not trust. DepthFirst's recommendation is direct: migrate untrusted and multi-tenant workloads to microVMs such as Firecracker (used by AWS Lambda and Fargate) or Kata Containers. Each microVM gets its own lightweight guest kernel, so even a successful kernel exploit compromises only that ephemeral instance — the host and neighboring tenants stay intact. It is the only response that addresses the architecture rather than the specific CVE.

For everything that must stay in containers, the checklist is short and uncomfortable. Check which Ubuntu kernel flavor your nodes actually run — the stock 22.04 kernel is not affected, but the 6.8-based HWE and the cloud kernels for 22.04 are, and 24.04/26.04 mainline variants are vulnerable. Apply the upstream patch directly if your distribution lags and you can test a rebuild. Watch Ubuntu security notices for the kernel USN and treat the reboot slot as urgent, not scheduled. And if the workload is untrusted — third-party code, customer code, anything multi-tenant — ask whether it needs a shared kernel at all.

The era where containers were assumed to be a robust isolation boundary is over; that is DepthFirst's title, and the timeline of this CVE is its evidence. Infrastructure that assumes the kernel can be breached has to stop putting the kernel in reach. More infrastructure and container-security analysis is on neticslabs.com.

Sources

Source: Containers Are No Longer a Security Boundary — depthfirst.com/research, 2026-09-22. Source: CVE-2026-80521 — ubuntu.com/security/CVE-2026-80521, updated 2026-09-24. Source: Ubuntu Container Escape Vulnerability Gets Public Exploit Before Kernel Patch Arrives — linuxjournal.com, 2026-09-22. Fix commit: af_unix: Unlink scc_entry in unix_del_edge() — git.kernel.org, commit 594d905195024b228c962627ae5ae7c17bd582a4. Internal linkage: copy-fail container security analysis and the Kubernetes v1.37 storage-hardening piece.

Source: Containers Are No Longer a Security Boundary — depthfirst.com/research, 2026-09-22, with the Ubuntu CVE tracker (updated 2026-09-24) and Linux Journal (2026-09-22) for patch status and context.