CVE-2026-80521 is not a Docker CVE. It is a Linux kernel bug that a container can reach, because the socket family it lives in is allowed by the default Docker and Kubernetes seccomp profiles. The Hacker News reported on September 23 that DepthFirst published research on September 22, with exploit code aimed at Ubuntu 26.04. Ubuntu’s tracker, last updated September 21, still lists the vulnerable packages as vulnerable. Patching the Docker daemon will not close this. The package you need is a kernel, and for several of those packages Canonical has not shipped it.
If you already lived through Fragnesia on GKE Ubuntu nodes, the shape will feel familiar: a host bug, a container-shaped headline, and a tracker that does not match the blog posts line for line. The difference is the disagreement is about Ubuntu 22.04, and that disagreement is the useful part.
What CVE-2026-80521 is, without the recipe
DepthFirst, as reported by The Hacker News, describes a use-after-free in the kernel’s garbage collector for AF_UNIX sockets. That collector cleans up file descriptors passed between processes. AF_UNIX is local process communication. It is allowed by default in Docker and Kubernetes seccomp profiles, which is why a process inside a container can reach the bug. The impact they published is a container escape to root on the host. CVSS v3.1 base score is 7.8, high. Ubuntu’s vector string on the tracker is CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. Local, low complexity, low privileges, no user interaction, high impact on confidentiality, integrity, and availability.
I am not going to describe how the collector is abused. A public exploit exists. Repeating its steps does not help you patch. The facts that change an operations decision are the ones above: host kernel, reachable from a default container profile, escape to host root, score 7.8, and no Ubuntu package yet for the releases the tracker marks vulnerable.
Ubuntu’s own priority is Medium. The page was published August 26 and last updated September 21. Priority Medium next to a 7.8 is not a reason to wait. It is a reason to read the status column instead of the priority badge. The tracker also says the fix commits, for information only, are an introduction at 4090fa3 and a fix at 594d905, and it tells you not to cherry-pick. Take that sentence literally. A hand-applied commit on a production kernel is how you get a node that no longer matches any security pocket and still is not the build Canonical will support.
The upstream timeline is ahead of Ubuntu, and that gap is the incident. Linux Journal says DepthFirst reported the issue to the kernel security team on August 5. The Hacker News says the upstream fix landed on August 6 in mainline kernel 7.2 and in stable 7.1.10. The vulnerable code was introduced in 6.10 and also backported to stable 6.1 and 6.6. So the bug is old enough to be in kernels people still run, and the fix is old enough that “wait for upstream” is no longer the sentence. Upstream already moved. The distribution has not, for the packages marked vulnerable.
The Hacker News says the flaw is not in CISA’s Known Exploited Vulnerabilities catalog, and that there were no confirmed reports of attacks using it at the time of that piece. Linux Journal, writing with a September 23 cutoff, says the same about in-the-wild exploitation. Absence from the KEV list is not a mitigation. It means you do not have a federal deadline. You still have a public exploit and an unfixed package.
The tracker and the headlines do not agree on 22.04
This is the section to read twice if your estate is mixed.
On Ubuntu’s tracker, the stock linux package is “Vulnerable, work in progress” on 26.04 LTS (resolute) and “Vulnerable” on 24.04 LTS (noble). On 22.04 LTS (jammy) that same linux package is “Not affected.” 20.04 and older are not affected either. Linux Journal says the same thing about the standard 22.04 linux package, and adds the caveat that matters: systems using a newer HWE kernel or a specialized variant have to be evaluated separately. The distribution name is not the exposure.
The cloud flavors I could read on the tracker follow the same split for the package names that were actually in the extract:
| Package | 26.04 | 24.04 | 22.04 |
|---|---|---|---|
| linux | Vulnerable, work in progress | Vulnerable | Not affected |
| linux-aws | Vulnerable | Vulnerable | Not affected |
| linux-gke | Vulnerable | Vulnerable | Not affected |
| linux-ibm | Vulnerable | Vulnerable | Not affected |
| linux-oracle | Vulnerable | Vulnerable | Not affected |
Linux Journal specifically calls out Ubuntu 24.04 AWS kernels as vulnerable, alongside generic and newer HWE packages. That matches the linux-aws row. If your GKE nodes are Ubuntu, linux-gke on 26.04 and 24.04 is in the vulnerable column. 22.04 linux-gke is not affected on that row. Focal’s linux-gke is marked ignored, end of kernel support, which is a different problem and not a fix.
The Hacker News wrote, on September 23, that 24.04 and 22.04 are also affected through newer kernel packages, including AWS, Azure, and GCP, and that no fix had shipped on any affected release. The 24.04 half of that sentence matches the tracker. The 22.04 half does not match the stock linux, linux-aws, linux-gke, linux-ibm, or linux-oracle rows I am looking at, all of which say jammy is not affected. Both can be partly true if a newer HWE or a flavor that was not in the extract is vulnerable. I am not going to flatten that into “22.04 is safe” or “22.04 is owned.” The operational instruction is the one Linux Journal already gave: open the tracker and match the package name on the node. A release number will lie to you in both directions.
Azure and GCP package names were in The Hacker News summary and not in the tracker rows I extracted. Do not assume they copy the linux-aws row. Look them up. The page is the source of truth Canonical will update when a pocket actually contains a fix. A blog post will not flip that cell for you.
What to check on a Docker host
You need the kernel package, not the Docker version. These commands identify a host. They do not test the bug. Do not go looking for a proof-of-concept to “confirm” a production node. Confirmation is the package status.
On the node:
uname -r
. /etc/os-release && echo "$VERSION $VERSION_ID"
dpkg -l 'linux-image-*' | awk '/^ii/{print $2, $3}'uname -r is the running kernel. The dpkg line is the installed image packages, which may include a newer package you have not rebooted into, or an older one you have not removed. The string you take to the tracker is the package name, something like linux-image-aws or linux-image-gke, not “Ubuntu 24.04.” If the running kernel and the newest installed image disagree, you have a reboot debt that is separate from this CVE and will confuse the next person who screenshots uname.
Then open the CVE page and find that package under your release. Three statuses change the next action.
“Not affected” means this package is not the buggy one. Write down the package name you matched. A later HWE upgrade can move you into a different row. “Not affected” on jammy linux is not a permanent property of every kernel you might install next quarter.
“Vulnerable” or “Vulnerable, work in progress” means Canonical has not given you a pocket update yet, as of the September 21 refresh. The Hacker News said no fix had shipped on any affected release. Do not invent a version number and apt-pin it. Watch the tracker. When the status becomes a fixed version, install that package through the normal security pocket and reboot. Ubuntu’s own note on the page is that the commit IDs are informational and you should not cherry-pick.
“Ignored,” usually end of kernel support or end of standard support, means you are not going to get a fix on that flavor because the flavor is already dead. Those rows in the extract were mostly old point-releases, not the 24.04 and 26.04 packages this bug is about. If you are still on one of them, this CVE is not your only problem. Plan the move. Do not wait for a USN that the tracker has already declined to issue.
Neither DepthFirst nor Ubuntu has published a temporary workaround, according to The Hacker News. There is no sysctl in these sources that you can flip tonight and call it contained. Changing the Docker version, turning on rootless mode, or rewriting a seccomp profile are not the remediation the tracker is tracking. We have a rootless mode guide and a note on not handing agents the Docker socket. Both are still good ideas. Neither one replaces a kernel update for a bug in the host’s AF_UNIX collector. Rootless changes the daemon’s privileges. This bug is in the kernel the container shares with the host. I do not have a source that says a custom seccomp drop of AF_UNIX is a supported mitigation, so I am not going to prescribe one. If you already deny that socket family for an unrelated reason, do not undo it. If you do not, do not treat a Friday-night profile edit as the patch.
Untrusted containers do not share this kernel
The recommendation DepthFirst did publish, via The Hacker News, is for untrusted or multi-tenant workloads: move them to a microVM isolation boundary such as Firecracker or Kata Containers, where each workload gets its own kernel instead of sharing the host’s. Linux Journal makes the same point in operations language. A public exploit has been out since September 22. There is no confirmed widespread exploitation in the sources above. There is also no Ubuntu package for the vulnerable rows. The interval between those two facts is when a shared kernel is the wrong boundary for a container you do not trust.
That is a different project from apt upgrade. Kata or Firecracker is a runtime change, a performance change, and on Kubernetes a RuntimeClass change. It is justified for the workloads you would not put on a shared kernel even after this CVE is old: third-party CI jobs, customer code, anything that is already supposed to be sandboxed harder than a seccomp profile. It is a poor use of a weekend for a homelab running your own Compose file, where the practical move is to identify the package, subscribe to the tracker, and reboot when the fixed image exists.
If the host is 24.04 or 26.04 and the package row says vulnerable, treat every container on that kernel as inside the trust boundary of the host until the reboot into a fixed kernel. Network policy between containers does not cross this bug. A non-root user in the container does not, either. The CVSS vector says low privileges are enough. “We do not run privileged containers” is necessary and, for this one, not sufficient. Privileged containers are a worse idea this week than last week. They are not the condition the researchers required.
What I would do before the next image build
Make a list of container hosts. For each one, record release, uname -r, and the linux-image package name. Match those names to the tracker once, today, and again when you see a USN. Do not trust a fleet agent that only reports “Ubuntu 24.04.” That string covers a vulnerable generic kernel and would also cover a flavor you have not checked.
Separate the list into three piles. Not affected, with the package name written down. Vulnerable, waiting on Canonical, with untrusted workloads called out for a microVM conversation if they cannot wait. Ignored or end-of-support, which is a migration, not a CVE ticket.
Do not pull a mainline 7.2 kernel onto an Ubuntu node to “get the August 6 fix” unless that node is already on a kernel series you build yourself. The tracker exists so you do not do that. A node running a kernel Canonical did not ship will not receive the pocket update you are waiting for, and you will have traded a known gap for an unsupportable one.
When the status cell changes to a fixed version, the rest is ordinary. Install the security update, reboot, confirm uname -r moved, and only then tell anyone the host is clear. A package sitting in /boot without a reboot is not a patched kernel. We have said that on other kernel bugs. It is still the step people skip when the Slack thread feels finished.
Docker images you build tomorrow are not the delivery vehicle for this fix. Rebuild them if you have other reasons. Do not put a CVE-2026-80521 line in the image README and call the host done. The bug is under the runtime. The runtime is fine to keep updated. It is not the component Ubuntu marked vulnerable.
Check the tracker before you tell the fleet it is clear. As of the September 21 update, “work in progress” on 26.04 and “Vulnerable” on 24.04 are still the cells that matter, and a public exploit has been sitting next to them since September 22.
