containerd Patches Four Moderate Advisories on October 13 Across 2.4, 2.3, 2.2 and 2.0, With 2.0.14 Carrying Only a Disk-Exhaustion Fix

Overview

The containerd project published four patch releases on October 13, 2026: 2.4.2, 2.3.7, 2.2.10 and 2.0.14. Each release page describes itself as containing security patches or a security patch. Across the four, the release notes name four security entries: three GitHub security advisory (GHSA) identifiers and one CVE, CVE-2026-95839, which appears on the page of a fourth advisory, GHSA-vwhp-8p66-mq4f. The patched releases differ by branch, so which fixes a given node receives depends on the containerd line it runs.

What the advisories describe

Each of the four advisories below is rated Moderate on its GitHub advisory page.

• Malformed digest crash. GHSA-vwhp-8p66-mq4f, the advisory that carries CVE-2026-95839, describes an unrecovered panic when a child descriptor contains the io.containerd.manifest.subject annotation and a malformed digest. The advisory says pulling or importing such an image through the transfer service, including default CRI PullImage requests, crashes the containerd daemon. It lists fixes in 2.4.2, 2.3.7 and 2.2.10.
• Crafted Content-Length crash. GHSA-8647-2jxj-p2rc covers a daemon crash when pulling an image from an untrusted registry that returns a crafted Content-Length header. The advisory says it affects only configurations where concurrent_layer_fetch_buffer is set to enable parallel layer fetch, and that default configurations with the setting disabled are not affected. It also says existing running containers remain unaffected. The page lists “No known CVE” and fixes in 2.4.2, 2.3.7 and 2.2.10.
• Disk exhaustion. GHSA-hc94-p972-ch66 says containerd streams layer data into its content store without bounding incoming bytes to the declared size before validation, so a crafted image or malicious registry can keep writing until host disk space is exhausted. The advisory says that in Kubernetes this can trigger node disk pressure, render the kubelet and containerd unresponsive, and block new pod startup. It lists fixes in 2.4.2, 2.3.7, 2.2.10 and 2.0.14 and shows no known CVE.
• Checkpoint-restore leak. GHSA-5p7c-hggf-c748 concerns the CRI plugin on Linux, which can leak read-only mounts and pinned snapshots when restoring a container from a checkpoint image fails. The advisory lists fixes in 2.3.7 and 2.2.10 only, and states that containerd 2.4 does not support restore via the CRI plugin and is not vulnerable. It shows no known CVE.

What each release carries

Counting the identifiers in each release’s “Security Updates” section, the notes for 2.4.2 list CVE-2026-95839, GHSA-8647-2jxj-p2rc and GHSA-hc94-p972-ch66, which is three of the four advisories (the CVE belongs to GHSA-vwhp-8p66-mq4f). The notes for 2.3.7 and 2.2.10 list all four entries, including GHSA-5p7c-hggf-c748. The notes for 2.0.14 list only GHSA-hc94-p972-ch66. These lists match the “fixed in” lines on the four advisory pages.

The release notes also list hardening items under their highlights. All four releases state that they apply hardening to not follow symlinks for container log files and to allowlist socket domains in the default seccomp profile. Releases 2.4.2, 2.3.7 and 2.2.10 add hardening to reject image references with ”..” path components. Releases 2.3.7, 2.2.10 and 2.0.14 add hardening to filter ID-mapping labels from image annotations during unpack, while the 2.4.2 notes do not list that item. The 2.4.2 notes also list a fix for excessive memory usage during image pulls when registry downloads outpace content writes, and the 2.2.10 notes list a fix to avoid hang and data corruption during multipart image fetch. The release notes do not tie these hardening items to the advisories, and this article does not either.

Workarounds named in the advisories

All four advisory pages recommend restricting pod image references to trusted registries, with a Kubernetes ValidatingAdmissionPolicy or an admission webhook given as examples. For the Content-Length issue, the advisory says to keep concurrent_layer_fetch_buffer at 0, which it describes as the default, or omit it. For the checkpoint-restore leak, the advisory says that in containerd 2.3 and 2.2 operators can disable CRI checkpoint and restore support by setting enable_criu = false, or ensure enable_experimental_restore_via_create is false, which it describes as the default starting in containerd 2.3.4 and 2.2.7. It adds that administrators must unmount any lingering /tmp/checkpoint* mount points on the host, or reboot the node, to release resources from mounts leaked before the update.

What We Don’t Know

• The advisory pages and release notes do not say whether any of the issues has been exploited, and none of the sources read for this article address that.
• The containerd advisory index, when fetched for this article, listed ten advisories, three of them dated October 13: GHSA-8647-2jxj-p2rc, GHSA-vwhp-8p66-mq4f and GHSA-5p7c-hggf-c748. GHSA-hc94-p972-ch66 was not in that list, although its own page loads and shows an October 13 publication time of 22:50 UTC. The reason for the difference is not stated.
• The sources reviewed do not say whether releases outside 2.4, 2.3, 2.2 and 2.0 are affected or will receive fixes.
• Every claim here rests on the containerd project’s own GitHub release and advisory pages; no independent outlet’s coverage was found at the time of writing.