Containerd, an open-source container runtime, had an issue in CRI implementations before versions 2.3.2, 2.2.5, and 2.1.9. When a container is restored from a checkpoint, containerd mistakenly trusts CDI annotations found in the checkpoint image metadata instead of only using the pod's create-time specification. This flaw allows a user with pod-creation rights to insert arbitrary CDI edits—such as device node mappings or host mounts—into the restored container, bypassing Kubernetes resource allocation and device-plugin enforcement. Successful exploitation requires the node to have CDI enabled and a matching host CDI specification for the requested device; environments where CDI is disabled or lacking sensitive device specifications are unaffected. The fix is implemented in containerd 2.3.2, 2.2.5, and 2.1.9. This is an instance of improper input validation (CWE‑20) and mis‑directed boundary checks (CWE‑863).

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.