Containerd’s CRI checkpoint restore incorrectly restores the security state from checkpoint data instead of enforcing the requested container configuration. This flaw lets an attacker supply a crafted checkpoint that grants root privileges, full capabilities, no_new_privs, and seccomp state bypasses. The result is a process that runs with root privileges and full capabilities on the host, while the CRI status reports the requested configuration, creating a complete oversight of the container’s security context.

The vulnerability affects the containerd container runtime, specifically versions from 2.1.0 through the pre‑patch releases of 2.2.x and 2.3.x. The fix is applied in containerd 2.2.7 and 2.3.4, so any older release remains vulnerable. Containers that do not use CRI checkpoint restore are not impacted.

With a CVSS score of 7.8 the vulnerability is high severity. The EPSS score is less than 1%, and this vulnerability is not listed in the CISA KEV catalog. The likely attack vector requires an attacker to supply a malicious checkpoint file through the CRI interface, which is typically exposed by the kubelet. Successful exploitation gives the attacker root access with all capabilities and bypasses security controls, but it relies on the ability to create or upload a checkpoint. As the issue is wide‑spectrum and exploitable where CRI checkpoint restore is enabled, systems using that feature should prioritise remediation.