Containerd, an open‑source container runtime, contained a flaw in its CRI implementation prior to versions 2.3.2, 2.2.5, and 2.1.9. When a container is restored from a checkpoint, the runtime incorrectly trusts CDI (Container Device Interface) annotations found in the untrusted checkpoint image metadata instead of relying solely on the pod’s create‑time specification. This allows a user with pod‑creation privileges to insert arbitrary CDI edits, such as device node mappings or host mounts, into the restored container, thereby bypassing Kubernetes resource allocation and device‑plugin enforcement. The vulnerability requires that the node has CDI enabled and a matching host CDI specification for the requested device; nodes with CDI disabled or lacking sensitive device specifications are not affected. The consequence is a potential privilege escalation within the runtime, exposing host resources to untrusted containers.

The vulnerability exists in containerd for all versions older than 2.3.2, 2.2.5, and 2.1.9. It is only exploitable on nodes where CDI is enabled and contains a matching host CDI specification for the requested device; nodes that have CDI disabled or lacking sensitive device specifications are unaffected. The affected platform may also include Red Hat Hummingbird 1, which exposes the same containerd integration.

The CVSS score of 8.4 marks this as high severity. The EPSS score is less than 1 %, and the vulnerability is not yet listed in the CISA KEV catalog, indicating that broad public exploitation has not occurred. However, the attack path requires only pod‑creation privileges and an enabled CDI environment, conditions that exist in many Kubernetes clusters. Because the attacker can introduce arbitrary host mounts or device nodes, the impact can be a full privilege escalation inside the runtime. The low EPSS does not negate the risk to organizations that run vulnerable containerd versions.