CVE-2026-53492: Device Injection in containerd Checkpoint Restore

CVE-2026-53492 is an authorization flaw (CWE-863) in containerd's CRI that trusts Container Device Interface annotations inside checkpoint images, scored 9.6 critical. A user who can create pods can inject devices and host mounts. Upgrade to containerd 2.3.2, 2.2.5 or 2.1.9.

What's affected

containerd versions from 2.1.0 up to but not including 2.1.9, from 2.2.0 up to but not including 2.2.5, and from 2.3.0 up to but not including 2.3.2, per the GitHub advisory. Patched versions are 2.3.2, 2.2.5 and 2.1.9.

The advisory states two conditions. The node must have Container Device Interface (CDI) enabled, and it must hold a matching host CDI specification for the device being requested. Environments with CDI disabled, or without sensitive device specifications, are not affected.

The attacker needs permission to create pods, which is why the score shows low privileges required with a changed scope.

How to check if you're exposed

Check the container runtime version on each node:

containerd --version
kubectl get nodes -o wide

The second command shows the runtime version for each node in the CONTAINER-RUNTIME column. Compare it with the ranges above. Then check whether CDI is in play. The advisory names the default specification directories:

ls /etc/cdi /var/run/cdi

If both are empty or missing, and CDI is not enabled in your containerd config, the conditions for this CVE are not met. Also ask whether anyone restores containers from checkpoint images, since that is the path involved.

You can also run the free in-browser dependency scan or browse the Gold directory to see where this component shows up in your stack.

What to do now

1. List nodes by containerd version and note which run 2.1.x, 2.2.x or 2.3.x.
2. Upgrade to 2.1.9, 2.2.5 or 2.3.2, matching your release line, and drain nodes as you go.
3. Restrict who may restore containers from checkpoint images, especially images from outside your control.
4. If you do not use CDI, move or remove host CDI specifications from /etc/cdi and /var/run/cdi, which the advisory says removes the reachability.
5. Recreate any container that was restored from an untrusted checkpoint, since the advisory says smuggled configuration may remain.
6. Review who holds pod creation rights in each namespace and trim them.

Why it matters

Kubernetes decides what devices and mounts a pod receives at create time, through resource requests and device plugins. The advisory says that on restore, containerd kept CDI annotations from the checkpoint archive rather than relying only on the pod's create-time specification. Metadata inside an image became a source of authority, which it should never be.

The result is a bypass of resource allocation and device plugin enforcement. Arbitrary CDI edits, such as device nodes and host mounts, could be added to the restored container. The weaknesses are CWE-863, incorrect authorization, and CWE-20, improper input validation.

The record does not report exploitation in the wild, and the CVE is not in the CISA KEV catalog. The narrow conditions matter, but clusters with GPUs or other devices exposed through CDI are the places where a matching host specification is most likely to exist.

Try it yourself

Click through it at your own pace, or open it full screen.

Quick check

Sources

• containerd security advisory GHSA-33vj-92qq-66hc

Last reviewed: 19 October 2026.