CVE-2026-53488

In containerd versions prior to 2.3.2, 2.2.5 and 2.1.9, the CRI implementation improperly trusts CDI annotations from untrusted checkpoint image metadata during container restoration. A user with pod creation permissions can bypass standard Kubernetes resource allocation and inject arbitrary devices or host mounts into the restored container.

A vulnerability in containerd prior to versions 2.3.2, 2.2.5 and 2.1.9 allows an attacker with pod creation permissions to poison the local image cache via a crafted checkpoint image. Missing validation of image references in the checkpoint import process enables assigning an arbitrary local tag to a malicious image.

containerd prior to 1.7.35, 2.0.12, 2.2.8, and 2.3.5 has a flaw where the layer unpack handler repeatedly traverses directories for certain opaque whiteout configurations. A malicious image layer can trigger repeated directory traversals while opaque whiteouts are processed. Pulling or importing the image can consume CPU, delay container startup, and reduce image-pull concurrency for unrelated deployments.

containerd is an open-source container runtime. From 2.1.0 until 2.2.7 and 2.3.4, containerd's CRI CreateContainer checkpoint restore is vulnerable because CRIU restores process security state from checkpoint data instead of enforcing the destination ContainerConfig. An attacker who can create a container from a crafted checkpoint can supply restored credentials, capabilities, no_new_privs, and seccomp state. The restored process can run as root with full capabilities and no enforced seccomp filters while CRI status reports the requested configuration. Systems that do not use CRI checkpoint restore are not affected. This issue is fixed in versions 2.2.7 and 2.3.4.

A vulnerability in containerd (open-source container runtime) prior to versions 1.7.36, 2.0.13, 2.2.9, 2.3.6, and 2.4.1. A crafted OCI index graph can force very high CPU/memory usage during PullImage (before container start), causing long ContainerCreating stalls and, at larger sizes, node/runtime instability.

Prior to 1.7.35, 2.0.12, 2.2.8, and 2.3.5, containerd on Linux with the CRI plugin enabled can indefinitely block the drainExecSyncIO goroutine in internal/cri/server/container_execsync.go when CRI ExecSync is used by exec probes or lifecycle hooks that launch long-lived background child processes retaining standard input and output pipes. The input and output drain phase has no default timeout and did not stop when the request context was canceled.

A vulnerability in containerd allows reading arbitrary files on the host via kubectl logs. The bug occurs in the CRI plugin, which restores container.log from a checkpoint image without validating a symlinked path.

A vulnerability in containerd allows memory exhaustion via a maliciously crafted container image, causing an OOM kill of the containerd process and making the runtime API unavailable. Affected versions are prior to 1.7.33, 2.0.10, 2.1.9, 2.2.5, and 2.3.2.

In containerd prior to versions 1.7.32, 2.0.9, 2.2.4, and 2.3.1, containers with a numeric User directive that cannot be parsed as a 32-bit integer are incorrectly treated as a username. This allows bypassing the Kubernetes runAsNonRoot restriction if a crafted image maps this large numeric string to root in /etc/passwd, causing the container to run as root (UID 0).