CVE-2026-95837 in containerd
Summary
by MITRE • 10/12/2026
containerd is an open-source container runtime. From 2.1.0 until 2.2.7 and 2.3.4, containerd's CRI CreateContainer checkpoint restore is vulnerable because CRIU restores process security state from checkpoint data instead of enforcing the destination ContainerConfig. An attacker who can create a container from a crafted checkpoint can supply restored credentials, capabilities, no_new_privs, and seccomp state. The restored process can run as root with full capabilities and no enforced seccomp filters while CRI status reports the requested configuration. Systems that do not use CRI checkpoint restore are not affected. This issue is fixed in versions 2.2.7 and 2.3.4.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/12/2026
The vulnerability identified within containerd, specifically affecting versions from 2.1.0 through 2.2.7 and version 2.3.4, represents a critical security flaw in the Container Runtime Interface checkpoint restore mechanism. This issue stems from a fundamental design error where the restoration process prioritizes data integrity over security policy enforcement during state recovery. When a container is restored from a previously created checkpoint, the system incorrectly retrieves and applies the security context directly from the saved checkpoint metadata rather than validating or enforcing the current CRI ContainerConfig provided by the orchestrator or user initiating the restore operation. This deviation creates a significant discrepancy between the actual runtime environment of the process and its reported configuration status, effectively bypassing intended isolation boundaries.
From a technical perspective, this flaw allows an attacker with the ability to create containers from crafted checkpoint data to manipulate the security state of the restored container. Specifically, the vulnerability enables the restoration of arbitrary credentials, allowing processes to run as root even if non-root execution was configured in the current request. Furthermore, it permits the retention or elevation of Linux capabilities that should have been stripped according to the destination configuration. The no_new_privs flag, which is designed to prevent privilege escalation via setuid binaries and other mechanisms, can also be bypassed by restoring a checkpoint where this flag was disabled. Additionally, seccomp filters, which restrict system calls to limit potential attack surfaces, are restored from the checkpoint data rather than being reapplied based on the current security profile, leaving the process with unrestricted or overly permissive syscall access despite what the CRI status reports as enforced restrictions.
The operational impact of this vulnerability is severe, particularly in environments utilizing Kubernetes or other orchestrators that rely heavily on containerd for workload management. An attacker who can influence checkpoint creation and subsequent restoration could achieve full root privileges within a container with capabilities equivalent to those of the host kernel user namespace, effectively breaking out of standard container isolation constraints if combined with other exploitation techniques. This misalignment between reported status and actual runtime state complicates security auditing and monitoring, as tools relying on CRI status information would incorrectly assume that strict security policies are in place when they are not. Systems that do not utilize the CRI checkpoint restore feature remain unaffected by this specific flaw, limiting the attack surface to deployments actively leveraging container snapshotting for migration or backup purposes.
This vulnerability aligns with CWE-250, which describes execution with unnecessary privileges, and CWE-693, Protection Mechanism Failure, as the system fails to enforce security policies during a critical state transition. In terms of MITRE ATT&CK mapping, this flaw facilitates lateral movement within containerized environments by allowing an attacker to escalate privileges from a restricted user context to root without triggering standard privilege escalation detection mechanisms due to the masked configuration status. To mitigate this risk, organizations must immediately upgrade containerd to version 2.2.7 or later, where the restore logic has been corrected to enforce the destination ContainerConfig over checkpoint data. Until upgrading is possible, administrators should restrict access to checkpoint creation and restoration APIs to trusted users only and ensure that security profiles are strictly validated before initiating any restore operations.