A flaw in CRI‑O checkpoint restore means that a pod built from a malicious checkpointed container can assign the restored process the original container’s credentials, capabilities, no_new_privs, and seccomp settings, instead of enforcing the destination pod’s security context. This bypass allows the attacker to run code with higher privileges inside the new pod, potentially moving across the container boundary and compromising host resources. The weakness is classified as CWE‑250, Unauthorized Use of Privileged Account.

Affected systems include Red Hat Enterprise Linux 8 and 9, Red Hat OpenShift Container Platform 4 (from version 4.17 onward), and Red Hat Confidential Compute Attestation. The vulnerability applies to any CRI‑O installation 1.34 or newer, covering the upstream 1.34, 1.35, 1.36 branches tied to the mentioned OCP releases.

The CVSS score of 8.8 reflects a high severity, yet the EPSS score is not available, suggesting the exploit probability is uncertain but potentially significant in environments that enable checkpoint/restore. The vulnerability is not yet listed in the CISA KEV catalog, but the attack requires the attacker to possess permission to create pods and the hostile checkpoint image to be present. If an RBAC policy permits pod creation by untrusted actors and the feature gate is enabled, exposure is high; otherwise disabling the feature gate mitigates the risk. In the presence of proper pod‑security standards and image‑policy controls the impact of a successful exploit can be further constrained.