CVE-2026-95837: 
Docker Compose vulnerability analysis and mitigation

CVE-2026-95837 is a privilege escalation vulnerability in containerd's CRI (Container Runtime Interface) plugin, specifically in the checkpoint restore functionality. When a container is restored from a crafted checkpoint via the CreateContainer API, CRIU (Checkpoint/Restore In Userspace) restores process security state — including credentials, Linux capabilities, no_new_privs, and seccomp filters — directly from checkpoint data rather than enforcing the destination ContainerConfig specified by the orchestrator. This allows an attacker with container creation permissions to run processes as root with full capabilities and no seccomp restrictions, while CRI status reporting masks the discrepancy. Affected versions are containerd 2.1.0 through 2.2.6 and 2.3.0 through 2.3.3; systems not using CRI checkpoint restore are unaffected. The vulnerability carries a CVSS v3.1 base score of 7.8 (High) (GitHub Advisory).

The root cause is improper privilege management (CWE-269): containerd's CRI CreateContainer code path conflates normal container creation with checkpoint restore, and during restore, delegates security state enforcement entirely to CRIU rather than re-applying the destination ContainerConfig's security policies. CRIU faithfully restores the checkpointed process's UID/GID credentials, Linux capabilities bitmask, no_new_privs flag, and seccomp profile from the checkpoint image, none of which are validated or overridden against the requested container configuration. An attacker who can supply a crafted checkpoint archive or annotated OCI image containing elevated security state can therefore cause the restored process to run as root with full capabilities and no seccomp enforcement. Compounding the issue, containerd's CRI status reporting reflects the requested (restricted) configuration rather than the actual restored state, hiding the privilege discrepancy from orchestrators such as Kubernetes (GitHub Advisory, Fix PR).

A successful exploit allows an attacker to escalate from a low-privileged container creation role to root with full Linux capabilities and no seccomp restrictions on the host node, resulting in high confidentiality, integrity, and availability impact. The attacker can read sensitive host files, modify container runtime state, and potentially escape the container to compromise the underlying node. Because the CRI status reports the requested (restricted) configuration, the privilege escalation is invisible to orchestrators, enabling persistent stealthy access and facilitating lateral movement within a Kubernetes cluster (GitHub Advisory).

No public proof-of-concept exploit code or in-the-wild exploitation has been reported as of the advisory date. The EPSS score is 0.0, indicating very low current exploitation probability, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. Exploitation requires local access with at least low privileges (permission to call the CRI CreateContainer API), making it relevant primarily to multi-tenant Kubernetes environments where untrusted users can submit workloads. The vulnerability was responsibly disclosed by researchers @l2yyd5 and @berkpolatCE (GitHub Advisory).

1. Identify a target: Confirm the target Kubernetes node runs containerd 2.1.0–2.2.6 or 2.3.0–2.3.3 with CRI checkpoint restore enabled (default in affected versions).
2. Craft a malicious checkpoint image: Create a CRIU checkpoint archive or annotated OCI image that encodes elevated process security state — specifically, UID 0 (root), a full Linux capabilities bitmask, no_new_privs = false, and an empty/permissive seccomp profile.
3. Submit a CreateContainer request: Using a CRI client (e.g., crictl) or a Kubernetes admission path with sufficient permissions, call CreateContainer referencing the crafted checkpoint archive as the container image source.
4. CRIU restores elevated state: containerd passes the checkpoint to CRIU, which restores the process with the embedded root credentials and full capabilities, ignoring the ContainerConfig security context.
5. Achieve privileged execution: The restored container process runs as root with full capabilities and no seccomp filters, enabling host filesystem access, capability abuse, or container escape, while crictl inspect reports the original restricted configuration (GitHub Advisory, Fix PR).

• Logs: containerd logs showing CreateContainer calls referencing .tar files or OCI images annotated as checkpoint data; absence of expected seccomp or capability enforcement errors during container creation from checkpoint sources.
• Process: Container processes running as UID 0 (root) with a full capabilities bitmask (CapEff: 0000003fffffffff) despite the pod/container spec specifying a non-root security context; child processes of the containerd shim with unexpected privilege levels.
• File System: Unexpected checkpoint archive files (.tar) in node-accessible directories or image registries; OCI images with CRIU checkpoint annotations (org.criu.image) from untrusted sources.
• Network: Outbound connections from container processes to external hosts that would be blocked under the expected seccomp/capability policy, indicating policy bypass (GitHub Advisory).

Upgrade containerd to version 2.2.7 or 2.3.4, which disable checkpoint restore via CreateContainer by default. containerd 2.4.0 removes the feature entirely. Running containers restored from untrusted checkpoints should be stopped, deleted, and recreated from trusted images. For operators who require the restore behavior on patched versions, it can be re-enabled by setting enable_experimental_restore_via_create = true in the [plugins."io.containerd.cri.v1.runtime"] section of config.toml, though this leaves the underlying vulnerability present. On unpatched versions, mitigate by restricting CreateContainer API access to trusted users, validating image registries via admission controllers, and rejecting images containing checkpoint annotations (GitHub Advisory, Fix PR).

The containerd project credited researchers @l2yyd5 and @berkpolatCE for responsible disclosure per the containerd security policy. The fix PR author (Samuel Karp) noted that checkpoint restore via CreateContainer was "implicated in several recent CVEs" and that the conflation of normal container creation with restore in a single API call was architecturally problematic, motivating the new dedicated RestorePod API (KEP-5823) as a longer-term replacement (Fix PR, GitHub Advisory).