CVE-2026-53493

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.

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).

The CRI plugin in containerd prior to versions 1.7.33, 2.3.2, 2.2.5, 2.1.9, and 2.0.10 propagates labels from an image config (LABEL instruction in Dockerfile) to a container without validation. This may allow arbitrary command execution on the host via a plugin that consumes container labels for operations.