Containers share the host kernel. That has always been the thin line between "isolated" and "mostly isolated," and on September 22, 2026, security research firm DepthFirst crossed it with a working container escape exploit for CVE-2026-80521. The bug is a use-after-free in the Linux kernel's AF_UNIX socket garbage collector. It lets an unprivileged process inside a default Docker or Kubernetes container break out of namespace isolation, cgroup boundaries, and seccomp filtering to get an interactive root shell on the host. The upstream fix has been available since August 6. Ubuntu has shipped it to zero LTS releases.
A public exploit exists. Your distro patch does not.
The gap between the upstream fix and any Ubuntu backport is now 50 days and counting, and the exploit code is on GitHub.
What exactly is the bug in the AF_UNIX garbage collector?
The vulnerability sits in the AF_UNIX socket subsystem, which handles local inter-process communication in the Linux kernel. Every time a process uses a local socket, connects to a local database, or relies on system services like systemd or Docker, it goes through this code. The specific flaw is in the garbage collection mechanism that cleans up SCM_RIGHTS messages, which let processes pass file descriptors to one another.
DepthFirst discovered the bug using an in-house AI model called dfs-large1, trained for vulnerability detection. They won a Google kernelCTF slot on July 24, 2026 with a zero-day exploit for this flaw. The bug is a race condition during garbage collection of SCM_RIGHTS messages that leads to a struct unix_vertex use-after-free. The fatal flaw: nothing removes the vertex from its persistent scc_entry ring before it is freed. If another socket in the same strongly connected component survives, that socket's scc_entry ring still contains a pointer to the freed vertex, and any subsequent cached walk through that ring dereferences deallocated memory.
The same bug was independently reported by someone at OpenAI named Kyle, according to the kernel security team's response to DepthFirst on August 5. The upstream fix landed the next day, August 6, 2026, in mainline kernel 7.2 and stable branch 7.1.10. The fix commit, 594d905195024b228c962627ae5ae7c17bd582a4 in net/unix/garbage.c, explicitly unlinks scc_entry before the vertex is freed so no cached walk can reach a deallocated object.
The vulnerable code was introduced in kernel 6.10 and backported to stable branches 6.1 and 6.6. Any kernel built from these branches without the fix commit is affected.
How does the exploit turn a kernel bug into a container escape?
Because all containers on a host share the same kernel, a kernel memory corruption bug is a container-escape bug by definition. The proof-of-concept released by DepthFirst successfully targets the latest Ubuntu 26.04 and gives an unprivileged container process an interactive root shell on the host. The CVSS v3.1 score is 7.8, rated High.
The exploit uses AF_PACKET sockets with PACKET_RX_RING for physical page anchoring and writable exact-PFN replacement mapping. This is where CAP_NET_RAW becomes relevant: the exploit needs that capability to set up the AF_PACKET primitive, and a default Docker or Kubernetes container configuration includes it. The technical writeup from The CyberSec Guru notes that the exploit chain breaks through namespace isolation, cgroup boundaries, and seccomp filtering to reach the host.
DepthFirst also released an exploit for a second vulnerability, CVE-2026-52910, demonstrating an escape against the latest Ubuntu 24.04. The broader argument in their research is that AI-assisted vulnerability discovery has lowered the barrier to finding and exploiting kernel bugs so significantly that container isolation can no longer be treated as a robust security boundary. They point to nearly 6,000 kernel CVEs published as of September 2026 as evidence of the attack surface.
This is not the first kernel container escape this year. We covered a similar Linux kernel flaw in our Bad Epoll kernel CVE guide, which also allowed root access through shared-kernel exploitation on Linux and Android. The pattern is clear: the kernel is the boundary, and the kernel is under sustained pressure.
Which Ubuntu releases are still unpatched?
The Hacker News reports that Ubuntu's security tracker lists the Linux package on 26.04 as "vulnerable, work in progress" as of September 25, 2026. The 24.04 and 22.04 releases are also affected through newer kernel packages, including cloud-optimized kernels for AWS, Azure, and GCP workloads. No fix has shipped on any affected release, and Ubuntu has published no remediation date.
The chart below shows the key intervals: 13 days from discovery to upstream fix, 47 days from fix to public exploit release, and 50 days from fix to today with no Ubuntu LTS patch available.
DepthFirst won the kernelCTF slot on July 24, reported the bug to kernel security on August 5, and the upstream fix landed on August 6 in mainline kernel 7.2 and stable branch 7.1.10. The public exploit went live on September 22. Ubuntu remains unpatched as of September 25. That is 50 days between the fix being available upstream and any Ubuntu customer getting it through their package manager.
The CVE is not in CISA's Known Exploited Vulnerabilities catalog, and there are no confirmed reports of attacks using it in the wild. But a reliable, target-specific proof-of-concept being public shrinks the gap between disclosure and weaponization. The exploit code is available, it works against a named distribution, and that distribution has not patched.
What should I do about it right now?
Neither Ubuntu nor DepthFirst has published a temporary workaround. Here is what you can do, ranked from most to least effective.
Patch the host kernel. The only complete fix is updating the host kernel to a build with the upstream patch. Upstream fixed releases are Linux 7.1.10 (stable) and 7.2 (mainline). Check your vendor's security advisory for the package version with the backport, because stable backports do not always keep the upstream version number. Running hosts need a reboot or a live kernel patch using kpatch or klp-convert. Updating container images does nothing here, since the vulnerable code lives in the shared host kernel, not in any container filesystem.
If you cannot wait for Ubuntu's package update, applying the upstream patch directly to the kernel source and rebuilding is an option. It carries operational risk and should be tested in staging first, but it closes the hole.
Drop CAP_NET_RAW from containers. The PoC uses AF_PACKET sockets with PACKET_RX_RING for physical page anchoring and writable exact-PFN replacement mapping. Removing CAP_NET_RAW is a partial mitigation. The underlying use-after-free still exists, and an attacker who finds an alternative page-anchoring technique could bypass it. But it raises the bar and costs nothing if your containers do not need raw socket access.
Move untrusted workloads to microVM isolation. DepthFirst's primary recommendation is migrating untrusted or multi-tenant workloads to microVMs. Firecracker, used by AWS Lambda and Fargate, and Kata Containers each give a workload its own guest kernel. A kernel exploit inside the microVM never reaches the host. This is the only measure that addresses the architectural problem directly.
If an exploit attempt fails, reboot the host. A failed exploit can leave the garbage collection worker holding unix_gc_lock. Stopping the container is not enough, because the lock and any memory corruption are host-kernel state. Isolate the affected host from the network and reboot into a patched kernel before restoring workloads. Do not try to recover the host in place.
The patch pipeline is the real vulnerability
The kernel team fixed this in two days from report to commit. Your distribution has had the fix for 50 days and has not shipped it. The exploit is public. Whether your container hosts get patched before attackers weaponize that exploit is the only open variable.
If you run containers on Ubuntu LTS in production, you are in a race you did not choose. The kernel is the boundary. The boundary has a hole. The patch exists but is not on your machine. Every day that gap stays open is a day your container isolation is a promise instead of a mechanism.
Sources
- DepthFirst - Containers Are No Longer a Security Boundary
- The Hacker News - Exploit Released for Unpatched Ubuntu Linux Flaw Enabling Host-Root Container Escape
- The CyberSec Guru - CVE-2026-80521: Ubuntu Kernel Flaw Lets Containers Escape to Host Root
