Someone left the prison door unlocked and published the blueprints on the internet yesterday
CVE-2026-80521 is a use-after-free in the Linux kernel's AF_UNIX socket garbage collector, introduced when the GC was rewritten to use a Strongly Connected Component (SCC) graph model in kernel 6.10 (later backported to 6.1.x and 6.6.x stable branches). When unix_del_edge() frees a vertex, it fails to call list_del_init(&vertex->scc_entry), leaving a dangling pointer in the cached SCC list. The next GC pass follows that pointer into freed memory. An unprivileged process inside a default Docker or Kubernetes container can win this race deterministically, reclaim the freed slab with controlled data, forge a fake vertex with a skb destructor pointing to call_umh_work, and land an interactive root shell on the host. Affected kernels span 6.1.x, 6.6.x, and 6.10 through 7.1.9; the fix landed upstream on August 6, 2026 in 7.1.10 and 7.2.
The vendor CVSS of 7.8 HIGH undervalues this bug dramatically. The vector AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H treats it as a standard local privilege escalation, but it ignores the container-escape dimension entirely — S:U (Scope: Unchanged) is wrong when the exploit crosses namespace, cgroup, and seccomp boundaries from an unprivileged container to host root. DepthFirst published a working exploit on September 22, 2026 — yesterday — and no Ubuntu LTS release has shipped a patch for any of its supported kernels, including AWS, Azure, and GCP variants. This is a zero-day gap for the most popular server Linux distribution.
5 steps from start to impact.
Gain code execution inside a container
- Code execution inside a Linux container or local shell on a host running a vulnerable kernel (6.1.x/6.6.x/6.10–7.1.9)
- Requires initial access — not remotely exploitable from the network without a prior foothold
Build cyclic AF_UNIX socket topology
SCM_RIGHTS to force the GC into the SCC fast-walk cached path. This involves creating ~252+ file descriptors per sendmsg() call. All syscalls used are permitted by Docker's default seccomp profile and Kubernetes' RuntimeDefault profile.- AF_UNIX sockets available (default in all container runtimes)
- SCM_RIGHTS descriptor passing available (default)
- None — these are core IPC primitives that cannot be disabled without breaking systemd, D-Bus, and container runtimes
Win the GC race condition
unix_add_edges() publishes a new edge before the skb is queued, and socket closure triggers GC, the partially freed SCC vertex remains linked via its scc_entry pointer. DepthFirst describes the race as deterministic after calibration, not probabilistic.- Timing control over GC scheduling (achieved via calibration, no special privileges)
- Race-condition exploits can be flaky across kernel versions and CPU architectures, but DepthFirst's published exploit handles this
unix_scc_dead() or soft-lockup warnings in dmesg; SIEM rules on kernel panic/oops patternsReclaim freed memory via AF_PACKET RX rings
AF_PACKET TPACKET_V1 RX ring allocations. It uses /proc/kpagecount as a physical page oracle to bypass KASLR and slab randomization. This step requires CAP_NET_RAW, which Docker grants by default but Kubernetes Pod Security Standards Restricted policy drops.- CAP_NET_RAW capability (Docker default, K8s Baseline allows it, only Restricted drops it)
- Access to /proc/kpagecount (available in default container mounts)
- Dropping CAP_NET_RAW blocks this specific reclamation primitive
- Restricting /proc/kpagecount access degrades the KASLR bypass oracle
- Kubernetes Restricted PSS would block this step
Forge fake vertex and execute host root shell
call_umh_work. When the GC follows the dangling scc_entry pointer and processes the forged vertex, it triggers controlled kernel code execution, spawning a usermode helper process as root on the host — outside all container isolation boundaries.- Successful memory reclamation from step 4
- KASLR bypass from /proc/kpagecount oracle
- If the slab reclamation fails or the KASLR bypass is blocked, the exploit degrades to a kernel panic (DoS) rather than code execution
The supporting signals.
| In-the-Wild Exploitation | No confirmed attacks as of 2026-09-23. Not listed in CISA KEV. However, a public weaponized exploit was released by DepthFirst on September 22, 2026 — exploitation is imminent, not theoretical. |
|---|---|
| Proof-of-Concept | Public exploit available. DepthFirst published a working container-escape exploit targeting Ubuntu 26.04 on 2026-09-22. The exploit achieves deterministic host root shell from an unprivileged default Docker container. DepthFirst won a Google kernelCTF slot on 2026-07-24. |
| EPSS Score | 0.00128 (low percentile) — EPSS has not yet caught up to the public exploit release. Expect a significant jump in the next EPSS update. |
| CISA KEV Status | Not listed as of 2026-09-23. Given the public exploit and unpatched distro status, KEV listing is likely if in-the-wild exploitation is confirmed. |
| CVSS Vector | CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H (7.8 HIGH). The S:U (Scope Unchanged) designation is arguably incorrect — the exploit crosses container isolation boundaries (namespaces, cgroups, seccomp) to reach the host kernel, which constitutes a scope change. |
| Affected Versions | Introduced in kernel 6.10 (commit 4090fa37), backported to 6.1.x and 6.6.x stable branches. Affects Ubuntu 22.04 LTS, 24.04 LTS, and 26.04 LTS including AWS, Azure, GCP, NVIDIA, OEM, and Realtime kernel variants. |
| Fixed Versions | Mainline 7.2 (commit 594d9051), stable 7.1.10 (commit e3702470). No Ubuntu, Debian, or RHEL patches have shipped as of 2026-09-23. Ubuntu tracker shows all affected releases as *work in progress*. |
| Scanning / Exposure | Not remotely scannable — requires local/container access. However, any Linux host running kernels 6.1.x/6.6.x/6.10–7.1.9 with containers is exposed. This encompasses a vast majority of Ubuntu cloud instances on AWS, Azure, and GCP. |
| Disclosure Timeline | 2026-07-24: DepthFirst wins kernelCTF slot. 2026-08-05: Reported to kernel security. 2026-08-06: Upstream fix merged (7.1.10, 7.2). 2026-08-26: CVE published. 2026-09-22: DepthFirst publishes exploit. 2026-09-23: No distro patches shipped. |
| Researchers | Kyle Zeng (independent kernel researcher, credited in upstream commit), DepthFirst (AI-assisted discovery using dfs-large1 model), OpenAI (independent report). Discovery partially AI-accelerated. |
Why this verdict
- Public weaponized exploit released yesterday: DepthFirst published a working container-escape exploit on 2026-09-22 targeting Ubuntu 26.04. The exploit is described as deterministic after calibration, not probabilistic. This eliminates the 'theoretical only' friction that normally tempers kernel race conditions.
- Zero distro patches available: Ubuntu 22.04, 24.04, and 26.04 — including all cloud kernel variants (AWS, Azure, GCP) — remain unpatched as of 2026-09-23. The upstream fix has been available since August 6, making this a 48-day patch gap with no relief in sight.
- Default container configurations are fully exposed: The exploit uses only AF_UNIX sockets, SCM_RIGHTS, and standard syscalls — all permitted by Docker's default seccomp profile, Kubernetes RuntimeDefault, and even Pod Security Standards Baseline. No
--privileged, noCAP_SYS_ADMIN, no kernel module loading. The only partial friction point isCAP_NET_RAWfor the AF_PACKET oracle, which Docker grants by default. - Role multiplier: The affected component is the Linux kernel itself — 100% of Linux installs run it by definition. Container hosts (Kubernetes workers, Docker hosts, CI/CD runners) represent a substantial and growing fraction of enterprise Linux deployments (conservatively >30%). On a Kubernetes worker node, container escape to host root means: (1) access to all pod secrets and service account tokens on that node, (2) ability to pivot to the kubelet credential and impersonate the node to the API server, (3) potential to compromise the entire cluster. On CI/CD runner hosts, container escape means supply-chain pivot. On database hosts running containerized databases, it means mass data exfiltration. The blast radius is fleet-scale to supply-chain-scale, and the affected component is canonically high-value — verdict floor is CRITICAL.
- Scope undercount in vendor CVSS: The vendor vector uses
S:U(Scope Unchanged), but the demonstrated attack crosses from an unprivileged container namespace to host root, definitively changing the security scope. A corrected vector withS:Cwould push the base score above 9.0.
Why not higher?
A score of 9.0 rather than 9.8+ reflects that the attack still requires initial code execution inside a container — it is not remotely exploitable from the network without a prior foothold. The CAP_NET_RAW requirement for the full exploit chain (while default in Docker) is droppable, and Kubernetes Restricted PSS does drop it, providing a partial population reduction. The exploit targets a specific slab allocator path that may need re-tuning across kernel minor versions and architectures.
Why not lower?
A public, deterministic exploit exists as of yesterday, no distribution patches are available, and the default configurations of Docker and Kubernetes are fully exposed. The affected component is the Linux kernel — every Linux server runs it — and container hosts are a canonical high-value deployment role representing well over 10% of the installed base. The demonstrated blast radius (container escape → host root → node takeover → cluster compromise) is fleet-scale. Downgrading below CRITICAL would require evidence that container hosts are a niche deployment pattern (they are not) or that the exploit is unreliable (DepthFirst says it is deterministic).
What to do — in priority order.
- Drop CAP_NET_RAW from all containers immediately — The DepthFirst exploit requires
CAP_NET_RAWfor theAF_PACKET TPACKET_V1physical page oracle that enables reliable slab reclamation and KASLR bypass. Dropping this capability degrades the exploit from deterministic code execution to a probabilistic kernel panic (DoS). In Docker:--cap-drop=NET_RAW. In Kubernetes: setsecurityContext.capabilities.drop: ["NET_RAW"]or enforce Pod Security Standards Restricted. Deploy within 3 days per noisgate mitigation SLA for CRITICAL. - Restrict /proc/kpagecount and /proc/kpageflags access from containers — The exploit uses
/proc/kpagecountas a physical page oracle to bypass KASLR and slab randomization. Mask or block these proc interfaces from container mount namespaces using AppArmor/SELinux profiles or OCI runtime configuration. Deploy within 3 days. - Enforce Kubernetes Pod Security Standards Restricted on all namespaces — PSS Restricted drops
CAP_NET_RAWand applies additional constraints that degrade the exploit chain. For clusters not yet using PSS, this is the single most impactful policy change. Apply namespace-level enforcement viapod-security.kubernetes.io/enforce: restrictedlabels. Deploy within 3 days. - Deploy Falco or Tetragon runtime detection rules — Add rules to detect: (1) rapid AF_UNIX socket creation (>100/sec from a single container), (2) large SCM_RIGHTS batches (252+ descriptors), (3) AF_PACKET RX-ring allocations from containers, (4) /proc/kpagecount reads from non-init namespaces, (5) unexpected process spawns outside container namespace hierarchy. These provide detection-in-depth while patches are unavailable. Deploy within 3 days.
- Migrate untrusted and multi-tenant workloads to microVM isolation — Firecracker, Kata Containers, or gVisor provide a hardware-level isolation boundary that kernel-level container escapes cannot cross. This is the only complete mitigation until kernel patches ship. Prioritize CI/CD runners, multi-tenant SaaS workloads, and any container running third-party or user-supplied code. Begin migration within 3 days; complete within 30 days.
- Apply upstream kernel 7.1.10 or 7.2 manually where distro patches are unavailable — The upstream fix (commit
594d9051) is a one-linelist_del_init()addition. For organizations with kernel build capability, cherry-picking or upgrading to 7.1.10/7.2 eliminates the vulnerability entirely. Test thoroughly before deploying to production — this is a kernel update. Target within 3 days for critical container hosts; deploy fleet-wide within noisgate remediation SLA of 90 days.
- Default Docker seccomp profile — does not block AF_UNIX sockets or SCM_RIGHTS, which are the core primitives the exploit uses. The default profile was never designed to prevent kernel exploitation via standard IPC.
- Kubernetes Pod Security Standards Baseline — allows CAP_NET_RAW, which the exploit requires for reliable slab reclamation. Only the Restricted level drops it.
- Network policies and firewalls — this is a local kernel exploit reachable via local IPC, not a network attack. Network segmentation provides zero protection.
- Container image scanning (Trivy, Snyk, Grype) — these scan for vulnerable packages inside images, not for host kernel vulnerabilities. They will not flag this CVE.
- Read-only root filesystem — the exploit operates entirely through syscalls and memory manipulation, never touching the filesystem.
readOnlyRootFilesystem: truedoes not help. - Custom seccomp profile blocking AF_UNIX — while technically effective, blocking AF_UNIX sockets breaks systemd, D-Bus, container runtimes (containerd/CRI-O communicate via AF_UNIX), and virtually every system service. This is not deployable in practice.
Crowdsourced verification payload.
Run this script on each target Linux host (not inside a container) as any user with read access to /proc/version_string and uname. No special privileges required. Example: chmod +x check_cve_2026_80521.sh && ./check_cve_2026_80521.sh
#!/bin/bash
# CVE-2026-80521 Checker — af_unix SCC entry use-after-free
# Checks if the running kernel is in the affected version range.
# Exit codes: 1=VULNERABLE, 0=PATCHED, 2=UNKNOWN
set -euo pipefail
KERNEL_VERSION=$(uname -r)
MAJOR=$(echo "$KERNEL_VERSION" | cut -d. -f1)
MINOR=$(echo "$KERNEL_VERSION" | cut -d. -f2)
PATCH=$(echo "$KERNEL_VERSION" | cut -d. -f3 | cut -d- -f1)
echo "[*] CVE-2026-80521 Check"
echo "[*] Running kernel: $KERNEL_VERSION"
echo ""
# Vuln introduced in 6.10 (commit 4090fa37), backported to 6.1.x and 6.6.x stable.
# Fixed in 7.1.10 and 7.2.
# Check if kernel has the fix applied via changelog/patch marker
if [ -f /proc/version ]; then
PROC_VERSION=$(cat /proc/version)
else
PROC_VERSION=""
fi
vulnerable=0
if [ "$MAJOR" -lt 6 ]; then
echo "[+] Kernel $MAJOR.x predates the vulnerable SCC GC rewrite (6.10)."
echo "PATCHED"
exit 0
elif [ "$MAJOR" -eq 6 ] && [ "$MINOR" -lt 1 ]; then
echo "[+] Kernel 6.$MINOR.x predates backported SCC GC code."
echo "PATCHED"
exit 0
elif [ "$MAJOR" -eq 6 ] && [ "$MINOR" -ge 1 ] && [ "$MINOR" -le 6 ]; then
# 6.1.x and 6.6.x received backports of the vulnerable SCC code
echo "[!] Kernel 6.$MINOR.x received SCC GC backport — likely VULNERABLE."
vulnerable=1
elif [ "$MAJOR" -eq 6 ] && [ "$MINOR" -ge 10 ]; then
# 6.10+ is where the SCC GC was originally introduced
echo "[!] Kernel 6.$MINOR.x contains original SCC GC code — VULNERABLE."
vulnerable=1
elif [ "$MAJOR" -eq 7 ] && [ "$MINOR" -eq 0 ]; then
echo "[!] Kernel 7.0.x predates the fix (7.1.10 / 7.2) — VULNERABLE."
vulnerable=1
elif [ "$MAJOR" -eq 7 ] && [ "$MINOR" -eq 1 ]; then
if [ -n "$PATCH" ] && [ "$PATCH" -ge 10 ]; then
echo "[+] Kernel 7.1.$PATCH contains the fix (>=7.1.10)."
echo "PATCHED"
exit 0
else
echo "[!] Kernel 7.1.$PATCH predates the fix (7.1.10) — VULNERABLE."
vulnerable=1
fi
elif [ "$MAJOR" -eq 7 ] && [ "$MINOR" -ge 2 ]; then
echo "[+] Kernel 7.$MINOR.x contains the fix (>=7.2)."
echo "PATCHED"
exit 0
elif [ "$MAJOR" -gt 7 ]; then
echo "[+] Kernel $MAJOR.x is newer than the fix."
echo "PATCHED"
exit 0
else
echo "[?] Could not determine vulnerability status for kernel $KERNEL_VERSION."
echo "UNKNOWN"
exit 2
fi
if [ "$vulnerable" -eq 1 ]; then
# Additional check: see if distro backported the fix
# Look for the fix commit message in kernel changelog if available
FIX_MARKER="594d905195024b228c962627ae5ae7c17bd582a4"
PATCHED_BY_DISTRO=0
if command -v dpkg &>/dev/null; then
CHANGELOG="/usr/share/doc/linux-image-${KERNEL_VERSION}/changelog.Debian.gz"
if [ -f "$CHANGELOG" ]; then
if zgrep -q "$FIX_MARKER" "$CHANGELOG" 2>/dev/null || zgrep -q "CVE-2026-80521" "$CHANGELOG" 2>/dev/null; then
PATCHED_BY_DISTRO=1
fi
fi
elif command -v rpm &>/dev/null; then
if rpm -q --changelog kernel-"$KERNEL_VERSION" 2>/dev/null | grep -q "CVE-2026-80521"; then
PATCHED_BY_DISTRO=1
fi
fi
if [ "$PATCHED_BY_DISTRO" -eq 1 ]; then
echo "[+] Distro has backported the CVE-2026-80521 fix."
echo "PATCHED"
exit 0
fi
# Check if containers are running (amplifies risk)
CONTAINER_RISK=""
if command -v docker &>/dev/null && docker info &>/dev/null 2>&1; then
RUNNING=$(docker ps -q 2>/dev/null | wc -l)
if [ "$RUNNING" -gt 0 ]; then
CONTAINER_RISK=" ($RUNNING Docker containers running — container escape risk is ACTIVE)"
fi
fi
if command -v crictl &>/dev/null; then
PODS=$(crictl pods -q 2>/dev/null | wc -l)
if [ "$PODS" -gt 0 ]; then
CONTAINER_RISK=" ($PODS Kubernetes pods running — container escape risk is ACTIVE)"
fi
fi
echo ""
echo "[!] VULNERABLE — kernel $KERNEL_VERSION is affected by CVE-2026-80521$CONTAINER_RISK"
echo "[!] Upgrade to kernel >= 7.1.10 or >= 7.2, or apply distro patch when available."
echo "VULNERABLE"
exit 1
fi- The Hacker News — Exploit Released for Unpatched Ubuntu Linux Flaw
- Ubuntu Security Tracker — CVE-2026-80521
- The CyberSec Guru — Ubuntu Kernel Flaw Lets Containers Escape to Host Root
- ByteIota — Ubuntu's Unpatched Container Escape Has a Public Exploit
- Ratatoskr — Upstream Patch (af_unix: Unlink scc_entry in unix_del_edge)
- OpenCVE — CVE-2026-80521 Details
- OSV — CVE-2026-80521
- Privacy Needle — Ubuntu Linux Flaw Enables Container Escape
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.