CVE-2026-53492

What it actually does

CVE-2026-53492 is an improper input validation flaw in containerd's CRI checkpoint-restore handling. Before containerd 2.3.2, 2.2.5, and 2.1.9, containerd preserves Container Device Interface (CDI) annotations embedded in untrusted checkpoint image metadata when restoring a container, instead of deriving CDI configuration only from the Kubernetes pod specification created through normal admission, scheduling, resource quota, and device plugin paths. A user who can create pods and trigger restoration from a crafted checkpoint can cause containerd to apply arbitrary CDI edits that correspond to existing host CDI specifications, potentially adding device nodes, host mounts, or other CDI-defined container modifications that the pod was not authorized to receive. Impact is primarily integrity and isolation bypass: unauthorized access to host devices or mounts and privilege expansion inside the restored container. Exploitation depends on CDI being enabled on the node and a matching sensitive CDI specification being present on the host.

Why it matters to the business

Organizations using Kubernetes or other CRI-based platforms with containerd checkpoint restoration and CDI enabled could have workload isolation and device governance bypassed by a low-privileged user with pod creation rights. In practical terms, this may allow unauthorized access to GPUs, accelerators, specialized hardware, or host paths exposed through CDI, undermining multi-tenant cluster controls, chargeback/resource allocation, compliance boundaries, and data protection assumptions. The issue is not known to be exploited in the wild, has low EPSS probability, is not in CISA KEV, and requires specific CDI/checkpoint-restore conditions, but the high integrity and scope impact means affected clusters should still be patched during the next prioritized container platform maintenance window, faster for shared or multi-tenant clusters.

How an attack unfolds

An attacker first needs legitimate permissions to create pods or otherwise submit workloads that can be restored from checkpoint images on a node using containerd's CRI implementation. They craft or modify checkpoint archive metadata to include CDI-related annotations referencing a device name that matches a CDI specification already installed on the target node. During restore, vulnerable containerd versions trust and preserve those annotations from the checkpoint metadata. Instead of enforcing only the pod's create-time device requests and Kubernetes device plugin allocation decisions, containerd applies the CDI edits from the checkpoint. If CDI is enabled and the referenced CDI spec exists, the restored container may receive unauthorized device nodes, host mounts, environment changes, or other CDI-defined access. The attacker then uses the restored container to interact with resources they were not allocated, potentially gaining access to sensitive host-exposed devices or mounted host content.

How to fix it

Upgrade containerd to a fixed release: 2.3.2 or later for the 2.3.x branch, 2.2.5 or later for the 2.2.x branch, or 2.1.9 or later for the 2.1.x branch. If packaged through a Linux distribution, Kubernetes distribution, or managed platform, install the vendor-provided containerd update that includes this fix and restart containerd according to vendor guidance, draining nodes first where needed to avoid workload disruption. As interim mitigation, disable CDI on nodes that do not require it, restrict or disable container checkpoint-restore functionality where possible, tightly limit RBAC permissions for pod creation and restore workflows, and remove unnecessary or overly broad CDI specifications from nodes. For multi-tenant clusters, review admission policies to prevent untrusted users from restoring arbitrary checkpoint archives and to constrain workloads to approved runtime features.

How to confirm the fix worked

Confirm each node is running a fixed containerd version by checking `containerd --version`, package manager inventory, node image version, or platform release notes. Validate that nodes using affected branches are at least 2.3.2, 2.2.5, or 2.1.9. Review containerd configuration to determine whether CDI is enabled and inspect CDI spec locations, commonly `/etc/cdi` and `/var/run/cdi`, for sensitive device definitions. Confirm whether checkpoint restore is enabled or exposed to users in the cluster. In Kubernetes, review RBAC to identify principals with pod creation and restore-related capabilities. After patching, perform a controlled negative test in a non-production environment: attempt to restore a checkpoint containing unauthorized CDI annotations and confirm containerd ignores checkpoint-supplied CDI annotations unless they are validly present in the pod's create-time specification.

Typical attack path

1. Attacker obtains or already has Kubernetes permissions sufficient to create pods and use container checkpoint restore functionality.
2. Attacker identifies or infers that target nodes run vulnerable containerd with CDI enabled.
3. Attacker determines a CDI device name present on the node, such as a GPU, accelerator, or other host device described by a CDI specification.
4. Attacker creates or modifies a checkpoint image archive so its metadata contains crafted CDI annotations referencing that device.
5. Attacker submits a workload restore using the malicious checkpoint metadata.
6. Vulnerable containerd preserves the checkpoint CDI annotations and applies CDI edits during container restoration.
7. The restored container starts with unauthorized device nodes, host mounts, or other CDI-provided access not granted through normal Kubernetes resource allocation.
8. Attacker uses the added access to read, modify, or interact with protected host resources or devices.

How to detect it

Investigate Kubernetes audit logs, containerd logs, kubelet logs, node system journals, and runtime event records for container restore operations involving checkpoint images and CDI annotations. Focus on activity after CDI was enabled and before the containerd fix was deployed. Look for pod creation or restore requests from non-administrative users, checkpoint archives with annotations containing `cdi.k8s.io/`, restored containers receiving devices not declared in their pod resource requests, and unexpected mounts or device nodes inside restored containers. On nodes, inspect `/etc/cdi` and `/var/run/cdi` for device specs that could have been targeted and compare their device names with workload annotations and runtime logs. Review Kubernetes audit events for unusual workload creation by service accounts or users that normally do not manage low-level runtime features. For forensic triage, compare the pod spec's declared resources and annotations against the actual OCI/runtime configuration and container filesystem/device view; discrepancies may indicate exploitation. No public exploit maturity, named threat actor activity, KEV listing, or ransomware use is currently reported, so detection should focus on abuse of checkpoint restore plus CDI rather than known campaign-specific indicators.

• cdi.k8s.io/
• /etc/cdi
• /var/run/cdi
• io.kubernetes.cri-o.Devices
• io.containerd.runc.v2
• checkpoint
• restore
• restored container
• containerd
• Container Device Interface

What your security team should do

• Inventory Kubernetes and CRI nodes running containerd and identify versions prior to 2.3.2, 2.2.5, or 2.1.9.
• Prioritize patching shared, multi-tenant, research, CI/CD, GPU, accelerator, and other device-heavy clusters where CDI is enabled.
• Check whether CDI is enabled and remove unnecessary CDI specifications, especially those granting host mounts or sensitive device access.
• Restrict pod creation and checkpoint-restore workflows to trusted administrators or controlled automation until all nodes are fixed.
• Review admission control, RBAC, and runtime policies to ensure untrusted users cannot supply arbitrary checkpoint images for restoration.
• Search logs and audit records for recent checkpoint restore activity involving CDI annotations or unexpected device allocations.
• After upgrade, verify all nodes restarted the fixed containerd binary and no vulnerable node pools remain schedulable.