CVE-2026-53492: 
Packer 脆弱性の分析と軽減

CVE-2026-53492 is a CDI annotation smuggling vulnerability in containerd's Container Runtime Interface (CRI) implementation, allowing users with pod creation permissions to bypass Kubernetes resource allocation and device plugin enforcement by injecting arbitrary Container Device Interface (CDI) annotations from untrusted checkpoint image metadata during container restoration. It affects containerd versions 2.1.0–2.1.8, 2.2.0–2.2.4, and 2.3.0–2.3.1. The vulnerability was disclosed on June 18–19, 2026, and patched versions were released concurrently. It carries a CVSS v3.1 base score of 9.6 (Critical) and a CVSS v4.0 base score of 8.4 (High) (GitHub Advisory, containerd Advisory).

The root cause is improper input validation (CWE-20) combined with incorrect authorization (CWE-863) and reliance on untrusted inputs in a security decision (CWE-807). When containerd restores a container from a checkpoint image, its CRI implementation preserves CDI-related annotations embedded in the checkpoint archive metadata rather than exclusively using the pod's original create-time specification. An attacker can craft a malicious checkpoint image containing arbitrary CDI annotations — such as references to sensitive device nodes or host filesystem mounts — which containerd then applies to the restored container without validating their legitimacy against the pod's authorized specification. Exploitation requires the attacker to have pod creation permissions on a node where CDI is enabled and a matching host CDI specification exists for the requested device (containerd Advisory, Red Hat Bugzilla).

Successful exploitation allows a low-privileged user with pod creation permissions to gain unauthorized access to host device nodes and host filesystem mounts that should be restricted by Kubernetes device plugin enforcement and resource allocation controls. This results in high integrity and confidentiality impact on the subsequent (host) system, as the attacker can read sensitive host data or manipulate host devices from within the restored container. The vulnerability effectively enables a container escape or privilege escalation path in environments with CDI-enabled nodes and sensitive device specifications, potentially facilitating lateral movement across the cluster (GitHub Advisory, containerd Advisory).

There is no public proof-of-concept exploit code and no evidence of in-the-wild exploitation at this time (GitHub Advisory). The EPSS score is approximately 0.48%, indicating a low near-term exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation is not fully automated (NVD SSVC: not automatable) and requires the attacker to already possess pod creation permissions and access to a CDI-enabled node with relevant device specifications, limiting the attack surface (GitHub Advisory).

1. Reconnaissance: Identify a Kubernetes cluster node running a vulnerable version of containerd (2.1.0–2.1.8, 2.2.0–2.2.4, or 2.3.0–2.3.1) with CDI enabled and sensitive CDI device specifications present in /etc/cdi or /var/run/cdi.
2. Obtain pod creation permissions: Acquire a Kubernetes service account or user credential with at least pod creation (create pods) RBAC permissions on the target namespace.
3. Craft a malicious checkpoint image: Create or modify a container checkpoint archive to embed arbitrary CDI annotations in its metadata, referencing a sensitive host device (e.g., a GPU device node or privileged host mount) that has a matching CDI specification on the target node.
4. Initiate checkpoint restore: Use the Kubernetes API or containerd CRI to restore a container from the crafted checkpoint image, triggering containerd to process the embedded CDI annotations without validation.
5. Access restricted resources: The restored container is launched with the injected CDI edits applied, granting access to the specified host device nodes or host mounts, enabling data exfiltration, host filesystem access, or further lateral movement within the cluster (containerd Advisory, GitHub Advisory).

• Logs: containerd CRI logs showing container restoration from checkpoint images by non-administrative users; unexpected CDI device annotations appearing in container specs that differ from the original pod specification at creation time.
• File System: Unexpected or newly created checkpoint archive files in containerd storage directories; presence of unfamiliar CDI specification files in /etc/cdi or /var/run/cdi.
• Process/Container Behavior: Containers restored from checkpoints exhibiting access to device nodes or host mounts not present in the original pod specification; containers with unexpected device files mounted (e.g., /dev/nvidia*, /dev/dri/*, or other sensitive host devices).
• Kubernetes Audit Logs: Pod creation or checkpoint restore API calls from low-privileged service accounts, particularly those involving checkpoint image sources from untrusted or external registries.

Upgrade containerd to the patched versions: 2.3.2, 2.2.5, or 2.1.9. After upgrading, existing containers that were restored from untrusted checkpoints should be recreated to remove any smuggled CDI configuration. As a temporary workaround for unpatched systems, restrict the restoration of containers from untrusted checkpoint images, and if CDI is not required on the node, remove or relocate host CDI specifications from /etc/cdi and /var/run/cdi to eliminate the vulnerability's reachability. Additionally, limit pod creation permissions to trusted users only via Kubernetes RBAC (containerd Advisory, GitHub Advisory).

The vulnerability was responsibly disclosed by Robert Prast (@robertprast) and credited in the official containerd security advisory (containerd Advisory). AWS published a security bulletin (2026-046-aws) and a June 2026 security roundup blog post acknowledging the issue, and Amazon Linux advisories (AL2023, AL2, Nitro Enclaves) were issued promptly (AWS Security Bulletin). Google Cloud also referenced the vulnerability in its support bulletins and release notes. The issue was discussed on oss-security mailing lists and noted by security community members on Bluesky, with SecurityOnline.info covering it as part of a broader containerd critical vulnerability report.