Robertprast

**Name of the Vulnerable Software and Affected Versions** containerd versions prior to 2.3.2 containerd versions prior to 2.2.5 containerd versions prior to 2.1.9 containerd versions prior to 2.0.10 containerd versions prior to 1.7.33 **Description** The CRI checkpoint import process fails to validate image references specified within a checkpoint image's configuration. An attacker with permissions to create pods can use a crafted checkpoint image to force the system to pull a malicious image and assign it an arbitrary local tag, poisoning the node's local image cache. If other pods on the same node use the poisoned tag with an `IfNotPresent` or `Never` pull policy, they will execute the malicious image instead of the legitimate one, allowing the attacker to execute arbitrary code under the victim pod's identity. Additionally, some related issues can lead to host-root command execution during restore. **Recommendations** Update to version 2.3.2. Update to version 2.2.5. Update to version 2.1.9. Update to version 2.0.10. Update to version 1.7.33. Only allow trusted images to be pulled.

**Name of the Vulnerable Software and Affected Versions** containerd versions prior to 2.3.2 containerd versions prior to 2.2.5 containerd versions prior to 2.1.9 containerd versions prior to 2.0.10 containerd versions prior to 1.7.33 **Description** A bug in the CRI plugin allows the propagation of labels from an image config, specifically the `LABEL` instruction in a Dockerfile, to a container without proper validation. This can lead to the execution of arbitrary commands on the host system if a plugin that consumes container labels for its operations is used. **Recommendations** Update to version 2.3.2 Update to version 2.2.5 Update to version 2.1.9 Update to version 2.0.10 Update to version 1.7.33 Ensure that only trusted images are used.

**Name of the Vulnerable Software and Affected Versions** containerd versions prior to 2.1.9 containerd versions prior to 2.2.5 containerd versions prior to 2.3.2 **Description** A bug in the CRI plugin allows the restoration of `container.log` from a checkpoint image without validating a symlinked path. This can lead to an arbitrary file read on the host system when using `kubectl logs`. **Recommendations** Update to version 2.1.9. Update to version 2.2.5. Update to version 2.3.2. Ensure that only trusted images and checkpoints are used.

**Name of the Vulnerable Software and Affected Versions** containerd versions prior to 2.1.9 containerd versions prior to 2.2.5 containerd versions prior to 2.3.2 **Description** The CRI implementation improperly trusts Container Device Interface (CDI) annotations found within untrusted checkpoint image metadata during container restoration. Instead of relying solely on the pod's create-time specification, the system preserves CDI-related annotations from the checkpoint archive. This allows a user with pod creation permissions to bypass Kubernetes resource allocation and device plugin enforcement by injecting arbitrary CDI edits, such as device nodes and host mounts, into the restored container. This issue requires CDI to be enabled on the node and the presence of a matching host CDI specification for the requested device. **Recommendations** Update to version 2.1.9. Update to version 2.2.5. Update to version 2.3.2. Restrict the restoration of containers from untrusted checkpoint images. Remove or temporarily relocate host CDI specifications from the `/etc/cdi` and `/var/run/cdi` directories if CDI capabilities are not utilized on the node.