CVE-2026-92574 in Confidential Compute Attestation
Summary
by MITRE • 09/21/2026
A vulnerability in CRI-O checkpoint restore allows a user who can create a pod from a malicious checkpointed container to bypass the destination Kubernetes security context. The restored process may retain credentials, Linux capabilities, no_new_privs, and seccomp state from the checkpoint instead of enforcing the destination configuration. This can allow execution with elevated privileges across the container security boundary. Affected upstream supported versions are CRI-O 1.34 and later. Downstream Red Hat products are affected from OCP 4.17 onward. Fixes have been applied to supported branches but are not yet released. Exploitation requires permission to create a pod from a malicious checkpoint image and checkpoint restore functionality to be available.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/21/2026
The vulnerability in CRI-O represents a critical failure in the enforcement of container security boundaries during the restoration process, specifically affecting versions 1.34 and later upstream and Red Hat OpenShift Container Platform (OCP) 4.17 onward downstream. This flaw allows an attacker who possesses the permission to create a pod from a maliciously crafted checkpointed container image to bypass the destination Kubernetes security context entirely. The core technical issue lies in how CRI-O handles the restoration of system state when loading a previously saved container snapshot. Instead of applying the new, restrictive security policies defined by the target cluster or namespace configuration, the restored process retains critical attributes from the original checkpoint environment. This includes retaining elevated Linux capabilities such as CAP_SYS_ADMIN, preserving credential sets that may include root privileges, maintaining the no_new_privs flag state which prevents privilege escalation restrictions, and keeping seccomp profiles that might allow otherwise prohibited system calls. Consequently, a container started via this method can operate with significantly higher privileges than intended by the cluster administrator, effectively breaking out of the expected security isolation boundaries.
From an operational impact perspective, this vulnerability enables lateral movement and privilege escalation within a Kubernetes environment where checkpoint restore functionality is enabled. An attacker who has compromised a low-privileged pod or gained access to create pods in a namespace with appropriate permissions can exploit this mechanism to spawn a container that runs as root or with full host-level capabilities without triggering standard security alerts related to policy violations. This undermines the fundamental assumption of multi-tenancy and isolation within Kubernetes clusters, allowing malicious actors to potentially access sensitive data stored on nodes, intercept network traffic from other pods, or pivot further into the cluster infrastructure. The severity is heightened by the fact that this bypass occurs at the runtime level, meaning traditional pod security standards (PSS) or admission controllers may not detect the violation because the container appears to start normally but with hidden elevated privileges inherited from the checkpoint state.
This vulnerability maps directly to CWE-250, which describes execution with unnecessary privileges, as well as CWE-693, protection mechanism failure, due to the runtime failing to enforce security policies during a specific operation. In terms of MITRE ATT&CK for Kubernetes, this behavior aligns with T1611.002, Escape to Host via Misconfigured Permissions, and potentially T1548.003, Abuse Elevation Control Mechanism: Setuid and Setgid programs, if the retained capabilities allow modification of system binaries or permissions. The exploitation chain requires two primary conditions: first, the attacker must have RBAC permissions to create pods in a target namespace, and second, the CRI-O node must have checkpoint restore functionality enabled and accessible. While fixes have been applied to supported upstream branches and downstream Red Hat products, they are not yet released for general deployment, leaving current installations vulnerable until patches are distributed by vendors.
Mitigation strategies should focus on restricting access to pod creation privileges in environments where checkpointing is utilized or planned. Administrators must ensure that only highly trusted service accounts with minimal necessary permissions can initiate pod creations from external images or checkpoints. Additionally, enabling strict Pod Security Standards at the namespace level, particularly enforcing restricted profiles, may help limit the impact if an attacker manages to exploit this flaw by restricting available capabilities and seccomp profiles even before restoration occurs, although the vulnerability suggests these are overridden during restore. Until official patches are released, organizations should monitor for unusual privilege escalations or unexpected root-level processes within containers that were recently restored from checkpoints. It is also advisable to disable checkpoint restore functionality if it is not actively required by workloads, thereby removing the attack vector entirely. Regular auditing of RBAC policies and continuous monitoring of container runtime behavior using tools like Falco or Sysdig can help detect anomalies indicative of this exploitation attempt.