Summary
A vulnerability in containerd's CRI plugin allows a container restored from an untrusted checkpoint image via the CreateContainer API to bypass the destination security context and execute with elevated privileges. When restoring from a checkpoint archive or an annotated OCI image, CRIU restores process credentials, Linux capabilities, no_new_privs, and seccomp state directly from checkpoint data rather than enforcing the ContainerConfig supplied by the orchestrator. Additionally, containerd's CRI status reporting reflects the requested configuration rather than the actual restored process state, masking the privilege discrepancy from Kubernetes and other orchestrators. This issue affects Linux systems running containerd with CRI checkpoint restore enabled; users not utilizing CRI checkpoint restore are not affected.
Impact
An attacker who can cause a container to be restored from a crafted checkpoint image can execute processes as root with full capabilities and no enforced seccomp filters, regardless of restrictive security policies requested by the orchestrator. Because the CRI status reporting reflects the requested rather than actual configuration, the privilege escalation is not visible through standard Kubernetes inspection (kubectl describe pod, OPA/Gatekeeper admission checks on the API object). Running containers that were restored from untrusted checkpoints on unpatched versions should be treated as potentially compromised and recreated from trusted sources after upgrading.
Detection
Identify any containers in the cluster that were created or restored via the CreateContainer CRI API using a checkpoint source. Review containerd's audit log and the Kubernetes event log for pod creation events where the container spec includes a checkpoint annotation or image. Containers restored from checkpoints on affected versions may show a discrepancy between their declared security context and their actual process capabilities — verify with crictl inspect <container-id> against the output of cat /proc/<pid>/status (checking CapEff) on the node. Consult the CRIU image security documentation for guidance on validating checkpoint image provenance.
Mitigation
Upgrade to containerd 2.2.7 or 2.3.4, which disable checkpoint restore via CreateContainer by default. The feature has been removed entirely in containerd 2.4.0. After upgrading, stop, delete, and recreate any containers that were previously restored from untrusted checkpoints. Users who require checkpoint restore via CreateContainer can re-enable it with the enable_experimental_restore_via_create configuration option, but doing so leaves this vulnerability present — restrict container creation permissions to trusted users and validate checkpoint image registries when this option is enabled. On unpatched versions, restrict container creation permissions to trusted users, validate container image registries, and use admission controllers to reject images containing checkpoint data.