containerd Multiple Security Flaws

Host command execution in containerd's CRI plugin arises because labels from an image config (Dockerfile LABEL instruction) are propagated to the created container without validation; when a downstream plugin consumes those labels for operations (notably the restart-monitor's binary:// logger path), an attacker-controlled label value becomes an arbitrary command executed with host-root privileges. Affected releases are all containerd versions prior to 1.7.33, 2.0.10, 2.1.9, 2.2.5, and 2.3.2, meaning any environment that pulls and runs an untrusted image on a node using a label-consuming plugin is exposed to full container-to-host escape. No public exploit identified at time of analysis, and the issue is not listed in CISA KEV, so this is a high-severity, responsibly-disclosed flaw rather than one with confirmed active exploitation.

Kubernetes device-plugin and resource-allocation enforcement can be bypassed in containerd by a namespace user holding pod-creation rights, who restores a container from a maliciously crafted checkpoint image. The CRI restore path trusts Container Device Interface (CDI) annotations embedded in untrusted checkpoint metadata instead of the pod's create-time spec, letting the attacker smuggle arbitrary CDI edits (host device nodes and mounts) into the restored container. It affects containerd v2.1.0-2.1.8, v2.2.0-2.2.4 and v2.3.0-2.3.1; there is no public exploit identified at time of analysis and it is not listed in CISA KEV.

Arbitrary host file disclosure in containerd's CRI plugin lets an attacker read any file on the Kubernetes node via `kubectl logs` because the plugin restores `container.log` from a checkpoint image while blindly following a symlinked path. All containerd 2.x branches before 2.1.9, 2.2.5, and 2.3.2 are affected wherever container checkpoint/restore (CRIU-based) is used. There is no public exploit identified at time of analysis and it is not on CISA KEV, but the flaw was independently reported by numerous researchers and a vendor patch is available.

Checkpoint image poisoning in containerd's CRI implementation allows an attacker with pod-creation permissions to corrupt the node-local image cache, causing victim pods to silently execute malicious images in place of legitimate ones. The root cause is missing validation of image references embedded in checkpoint image configurations: containerd trusts attacker-controlled strings in the checkpoint archive to drive image pulls and local tag assignment. Subsequent pods using an IfNotPresent or Never pull policy then inherit the poisoned tag and execute arbitrary code under the victim pod's Kubernetes identity. No active exploitation has been confirmed (not in CISA KEV), and no public exploit code has been identified at time of analysis; vendor-released patches are available.

Memory exhaustion via maliciously crafted container image in containerd causes an OOM kill of the containerd process, rendering the container runtime API unavailable and disrupting orchestration layers including Docker Engine and Kubernetes control-plane components. CVE-2026-47262 is rated Moderate by the containerd project - lower than the four co-patched Critical/High CVEs - and is fixed across the full active supported release tree in versions 2.3.2, 2.2.5, 2.1.9, 2.0.10, and 1.7.33. No public exploit code has been identified and this vulnerability is not listed in the CISA KEV catalog at time of analysis.