Public AF_UNIX Exploit Breaks Ubuntu Container Isolation and Reaches Host Root

A public exploit for CVE-2026-80521 can turn limited code execution inside an Ubuntu container into root privileges on the underlying host.

The vulnerability is a use-after-free in the Linux kernel’s AF_UNIX socket garbage collector. It is reachable through ordinary system calls permitted by standard Docker and Kubernetes seccomp configurations, making default container controls ineffective against this attack path.

DepthFirst released working exploit code targeting Ubuntu 26.04. As of September 23, 2026, no attacks have been confirmed, and the vulnerability is not listed in the US Cybersecurity and Infrastructure Security Agency’s Known Exploited Vulnerabilities catalog. Consequently, there is no CISA remediation deadline.

The public exploit nevertheless raises the risk for platforms that run untrusted or semi-trusted containers on a shared kernel.

A race in AF_UNIX garbage collection creates the escape path

AF_UNIX sockets provide local interprocess communication and can transfer open file descriptors through SCM_RIGHTS messages. The kernel must track those transferred references and reclaim circular groups of sockets that are no longer reachable.

CVE-2026-80521 arises from a race inside that garbage-collection process.

Ubuntu attributes the report to Kyle Zeng. Its technical description uses three sockets—A, B, and X—to explain how the race develops:

1. Sockets A and B belong to linked reference groups, known as strongly connected components or SCCs, while X is associated with the group.
2. Concurrent operations send sk-B from sk-X to sk-B and close A and B.
3. During the send operation, unix_add_edges() publishes a new edge representing the B-to-B relationship.
4. A narrow interval exists before the socket buffer carrying that reference is inserted with skb_queue_tail().
5. If the close operations and garbage collection occur during that interval, the collector can classify the A-B group as dead.
6. B is not immediately freed because the collector cannot yet see the socket buffer holding the newly published reference.
7. A later collection pass follows B’s stale scc_entry into partially freed state.

The result is a use-after-free. The upstream correction, titled af_unix: Unlink scc_entry in unix_del_edge()., removes the internal SCC entry before freeing its associated vertex.

DepthFirst’s explanation reaches the same core conclusion: the collector can observe a published reference before it sees the data structure carrying that reference. Partial cleanup then leaves a persistent pointer directed at released memory.

Default container controls do not block the required calls

The vulnerability does not require remote access to the host. An attacker needs a low-privileged local execution context, such as control of a process inside a container.

That requirement is reflected in the 7.8 High CVSS score and vector:

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

The attack has low complexity, requires low privileges, and needs no user interaction. Successful exploitation can compromise host confidentiality, integrity, and availability.

AF_UNIX socket operations are normally available inside containers. Docker and Kubernetes seccomp profiles allow the relevant interfaces by default, so the exploit does not depend on an unusual or deliberately permissive configuration.

Once the kernel memory flaw is exploited, namespaces, cgroups, and seccomp filters cannot preserve the intended security boundary. Those mechanisms isolate processes while relying on the same host kernel. A kernel compromise operates beneath them.

This distinction matters for multi-tenant services, CI/CD runners, container-based development environments, and systems executing customer-submitted code. A process that should be confined to one container may instead obtain root control over the host and potentially affect other workloads sharing it.

Ubuntu exposure depends on the installed kernel package

Ubuntu’s package-level security tracker provides a more precise assessment than the operating-system release number alone.

The base linux package for Ubuntu 22.04 LTS is marked not affected. However, the linux-hwe-6.8 package on the same release is vulnerable. Administrators therefore need to inspect the kernel flavor and package stream actually installed.

The relevant published statuses are:

Package	Ubuntu release	Status
linux	26.04 LTS, Resolute	Vulnerable, work in progress
linux	24.04 LTS, Noble	Vulnerable
linux	22.04 LTS, Jammy	Not affected
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	Not affected
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	Not affected
linux-azure-6.8	22.04 LTS, Jammy	Vulnerable

Several older or superseded branches are marked not affected, not in release, ignored, or end of life. Examples include linux-kvm on Ubuntu 22.04, 20.04, and 18.04, as well as the 5.15 AWS, Azure, and HWE branches on Ubuntu 20.04.

The available Ubuntu advisory does not provide a status for a GCP-specific package. It also does not give a date for fixed Ubuntu builds.

An upstream patch exists, but Ubuntu remediation remains incomplete

The vulnerable kernel code was introduced in Linux 6.10 and backported to the 6.1 and 6.6 stable branches.

The upstream fix landed on August 6 in mainline kernel 7.2 and stable kernel 7.1.10. Organizations that maintain custom kernels can apply that change directly, subject to their normal testing and deployment processes.

That upstream availability does not mean every Ubuntu kernel stream has received a corrected package. Ubuntu still identifies multiple branches as vulnerable, with the Ubuntu 26.04 base linux package specifically marked as remediation in progress.

No temporary workaround has been published by Ubuntu or DepthFirst. There are also no disclosed exploit signatures, forensic artifacts, or reliable kernel-level indicators that defenders can use to identify attempted exploitation.

AI-assisted research produced a working kernel exploit

DepthFirst said its vulnerability-detection model, dfs-large1, identified the flaw with support from a human-operated testing harness. The company used the exploit to win a Google kernelCTF slot on July 24 and reported the issue to the kernel security team on August 5.

Kernel maintainers subsequently told DepthFirst that an OpenAI researcher had independently found the same bug. The CVE commit credits Kyle Zeng as the reporter.

The episode demonstrates more than automated bug triage. The research process led to a working container escape against Ubuntu 26.04, covering discovery, race analysis, exploitation, and validation against a practical target.

It also follows other kernel vulnerabilities involving AI-assisted research and host-root escalation. Public exploit availability has become a recurring operational problem for unpatched Linux hosts, rather than merely a measure of theoretical severity.

Defenders should prioritize kernel inventory and stronger isolation

Administrators should first map each container host to its installed kernel package and branch. Checking only whether a machine runs Ubuntu 22.04, 24.04, or 26.04 is insufficient because base, HWE, AWS, and Azure packages have different statuses.

Where feasible, affected custom kernels should receive the upstream correction. Ubuntu-managed systems should install fixed distribution packages as soon as they become available.

Until then, organizations should reconsider which workloads are allowed to share a kernel. DepthFirst recommends microVM-based isolation such as Firecracker or Kata Containers for untrusted code. These designs give workloads separate kernels, preventing a container kernel exploit from directly compromising the primary host kernel.

Monitoring should focus on unexpected host-level processes originating from container contexts, unexplained privilege transitions, and unauthorized changes to host files or runtime configuration. These are behavioral warning signs, not vulnerability-specific indicators.

The absence of confirmed attacks or a CISA KEV listing should not be mistaken for low exploitability. Working code is already public, and the affected interfaces are exposed inside standard container configurations.