FALCONINTERNET

CVE-2026-80521: Ubuntu's Container Escape Has a Public Exploit and No Patch

Security
CVE-2026-80521: Ubuntu's Container Escape Has a Public Exploit and No Patch

On September 22, security firm DepthFirst published working exploit code for CVE-2026-80521, a Linux kernel vulnerability that lets unprivileged code running inside a container break out and land as root on the host. The upstream fix has been available since August 6. Ubuntu's patch for the two affected long-term support releases — 24.04 (Noble) and 26.04 — still shows "work in progress" in Canonical's tracker.

What the Flaw Is

The vulnerability lives in the kernel's garbage collector for AF_UNIX sockets, the local inter-process communication mechanism used by systemd, D-Bus, and the Docker daemon itself. AF_UNIX was introduced in Linux 6.10, which is why Ubuntu 22.04 (Jammy) and 20.04 (Focal), both running older kernels, are not affected. Ubuntu 24.04 (Noble, kernel 6.8–6.11) and Ubuntu 26.04 are both in the vulnerable range.

The race condition works like this: unix_add_edges() publishes a socket edge to the garbage collector before skb_queue_tail() has finished queuing the associated buffer. If a close() call completes in that narrow window and the GC fires, the collector sees a reference it believes is safe to free but isn't. The resulting use-after-free allows arbitrary writes into kernel memory, which is enough for a full privilege escalation chain from container process to host root. CVE-2026-80521 carries a CVSS 3.1 score of 7.8 (High).

Why Containers Don't Protect You Here

The standard mental model of container security assumes the kernel enforces a hard boundary. That boundary only holds if the kernel itself is not exploitable. This flaw makes that assumption wrong — and the attack surface is unusually wide.

AF_UNIX sockets are allowed by Docker's default seccomp profile. They are allowed under Kubernetes' RuntimeDefault seccomp profile and even under the more restrictive Restricted Pod Security Standard. That means an attacker needs only the ability to run code inside a container — no unusual privileges, no exotic capabilities, no special pod configuration. In a multi-tenant environment, where multiple customers share a single host, a single compromised container is all that separates an attacker from every other tenant on the machine.

The exploit DepthFirst published on September 22 targets Ubuntu 26.04. The firm first demonstrated the technique in a Google kernelCTF slot on July 24; the kernel security team received the bug report on August 5, and the upstream patch merged into kernel 7.1.10 and 7.2 the following day. That the public exploit followed six weeks after the upstream fix is a fairly compressed disclosure window. It means the patch gap — the period between "fix exists" and "fix ships to your server" — is where real exposure lives.

Cloud Kernels Are Also Vulnerable

Ubuntu's security tracker lists the vulnerable packages across multiple kernel variants: linux, linux-aws, linux-azure, linux-gcp, linux-oracle, and architecture-specific builds including RISC-V and Nvidia-optimized variants. If you're running Ubuntu 24.04 or 26.04 on AWS EC2, Azure VMs, or Google Cloud, check the kernel variant your instances use — they are all listed as vulnerable with no published fix date.

What to Do Right Now

Until Canonical publishes a Ubuntu Security Notice (USN) with a patched kernel, the most direct mitigation is a custom seccomp profile that blocks socket() calls with the AF_UNIX domain (domain value 1). The profile can be applied per container or cluster-wide via Kubernetes Localhost seccomp profiles:

{
  "syscalls": [{
    "names": ["socket"],
    "action": "SCMP_ACT_ALLOW",
    "args": [{ "index": 0, "value": 1, "op": "SCMP_CMP_NE" }]
  }]
}

This allows all socket() calls except those creating AF_UNIX sockets. The trade-off: any containerized application that relies on Unix-domain sockets for internal communication (which is many of them, including apps that use D-Bus or the Docker socket itself) will break. Test before deploying broadly.

Ubuntu Pro subscribers should check whether a Livepatch module has been published for this CVE. Canonical's Livepatch service covers high-severity kernel vulnerabilities with hot patches that don't require a reboot; given the CVSS 7.8 score and public exploit, this is a likely candidate. The CVE page at ubuntu.com/security/CVE-2026-80521 will reflect availability when it lands.

For servers where none of the above is practical in the short term, restricting who can deploy containers — and auditing what's already running — reduces exposure. An attacker needs code execution inside a container first; that entry point matters.

The Bigger Pattern

What makes CVE-2026-80521 worth flagging beyond the specifics is the trend it represents. DepthFirst discovered this using an AI-assisted kernel fuzzer (dfs-large1), and they won a CTF slot with a working exploit in July — before the patch even existed upstream. The time from "AI-generated PoC wins a competition" to "public exploit released" was under two months. The bar for finding and weaponizing kernel vulnerabilities has dropped. Container security models that treat the kernel boundary as an absolute guarantee need to be revised.

At Falcon Internet, we run 24x7x365 NOC monitoring precisely because the window between a public exploit drop and active exploitation in the wild has gotten very short. Watching for kernel update USNs and applying them quickly is not optional infrastructure hygiene anymore — it's the first line of defense on any shared host.

Watch ubuntu.com/security/notices for the USN. When it drops, treat it as a same-day patch.

Need this handled instead of explained?

We do this for a living — talk to an engineer about your setup.