Container Device Interface Injection in containerd

Executive Summary

CVE-2026-53492 is a critical vulnerability in containerd's CRI implementation affecting versions prior to 2.3.2, 2.2.5, and 2.1.9. The issue arises because containerd improperly trusts Container Device Interface (CDI) annotations found in untrusted checkpoint image metadata during container restoration.

When a container is restored from a checkpoint, containerd preserves CDI-related annotations from the checkpoint archive instead of relying solely on the pod's original create-time specifications. This flaw allows a user with pod creation permissions to bypass Kubernetes resource allocation and device plugin enforcement.

As a result, an attacker can inject arbitrary CDI edits, such as device nodes and host mounts, into the restored container. Successful exploitation requires that the node has CDI enabled and contains a matching host CDI specification for the requested device.

Useful 0 Not Useful 0

Impact Analysis

This vulnerability can allow an attacker with pod creation permissions to bypass standard Kubernetes resource allocation and device plugin enforcement.

By injecting arbitrary CDI edits, such as device nodes and host mounts, into a restored container, the attacker can potentially gain unauthorized access to host devices or mount sensitive host directories inside the container.

This can lead to privilege escalation, unauthorized resource access, and compromise of container isolation, increasing the risk to the host system and other containers.

Useful 0 Not Useful 0

Detection Guidance

Detection of this vulnerability involves checking if your containerd installation is a vulnerable version (2.1.0 to 2.1.8, 2.2.0 to 2.2.4, or 2.3.0 to 2.3.1) and whether CDI is enabled on the node with matching host CDI specifications.

You should inspect containers restored from checkpoint images for unexpected CDI annotations or device nodes that were not part of the pod's original specification.

While no specific commands are provided in the resources, general commands to check containerd version and CDI status include:

• Check containerd version: `containerd --version`
• List running containers and their checkpoint status: `crictl ps` or `ctr containers list`
• Inspect container annotations for CDI entries: `ctr containers info <container_id>` or `kubectl describe pod <pod_name>`
• Check if CDI is enabled and host CDI specifications exist by inspecting the host directories where CDI specs are stored, typically `/etc/cdi` or `/usr/share/cdi`.

Useful 0 Not Useful 0

Mitigation Strategies

Immediate mitigation steps include upgrading containerd to a fixed version: 2.1.9, 2.2.5, or 2.3.2 or later.

If upgrading is not immediately possible, restrict the restoration of containers from untrusted checkpoint images to prevent injection of arbitrary CDI annotations.

If CDI is not used in your environment, remove or relocate host CDI specifications from their default directories to prevent exploitation.

Additionally, consider recreating containers that were restored from untrusted checkpoints to remove any smuggled CDI configurations.

Useful 0 Not Useful 0

Compliance Impact

The vulnerability allows users with pod creation permissions to bypass Kubernetes resource allocation and device plugin enforcement, potentially injecting arbitrary device configurations into restored containers. This improper authorization could lead to unauthorized access or manipulation of container environments.

Such unauthorized access or privilege escalation may impact compliance with standards and regulations like GDPR or HIPAA, which require strict controls over access to sensitive data and system integrity. However, the provided information does not explicitly discuss compliance implications or specific regulatory impacts.

Useful 0 Not Useful 0