Database/Container, Kubernetes & orchestration

containerd: CRI checkpoint restore takes process security state from the checkpoint, not the container config

CVSS 7.8CVE-2026-95837Container, Kubernetes & orchestrationcurated

Impact

When containerd restores a container from a CRI checkpoint, CRIU reinstates the process credentials, capabilities, no_new_privs flag and seccomp state recorded in the checkpoint instead of enforcing the destination ContainerConfig. Anyone able to create a container from a crafted checkpoint gets a process running as root with full capabilities and no seccomp filter, while CRI status reports the restricted configuration the operator asked for - so the node looks compliant to anything reading the API. On a GPU node that means a tenant workload escaping the confinement that was supposed to keep it away from the device files, the driver and its neighbours. Clusters that do not use CRI checkpoint restore are not affected.

Who can reach it

A local, authenticated actor who can create containers on the node (for example a tenant with pod-create rights, or a compromised component that can push a checkpoint image) on a cluster where CRI checkpoint restore is enabled.

What to do

Upgrade containerd to 2.2.7 or 2.3.4. Versions from 2.1.0 are affected. Upgrading containerd means restarting the runtime on each node, which in practice is a drain and restart rather than a hot patch on a GPU node with long-running jobs. If you cannot patch promptly, disable CRI checkpoint restore - a cluster that does not use it is not exposed.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-95837 https://github.com/containerd/containerd/security/advisories/GHSA-p7v4-vr35-mj6f https://github.com/containerd/containerd/commit/928c03c6898cad95f795300281fdff0dbc55a32f https://github.com/containerd/containerd/pull/13913

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.