CVE-2026-92574

Fixes and workarounds

Workaround

Upgrade (primary remediation): Update CRI-O to a fixed version once available: 1.36.6 (1.36.x branch), 1.35.9 (1.35.x branch), or 1.34.14 (1.34.x branch). For Red Hat OpenShift Container Platform, apply the corresponding OCP update when released. Until the fix is applied, the following measures reduce exposure: Disable checkpoint restore if not required: In OpenShift, container checkpoint/restore requires the ContainerCheckpoint feature gate, which is Tech Preview and not enabled by default. Clusters that have not explicitly enabled this feature gate are not exposed to this flaw. If it was enabled and is not actively needed, disable it. For standalone CRI-O, set enable_criu_support = false in crio.conf under [crio.runtime] and restart the CRI-O service. Restrict pod creation privileges: Limit Kubernetes RBAC for the create and update verbs on pods, deployments, daemonsets, statefulsets, jobs, and cronjobs resources to trusted users and service accounts only. Exploitation requires the ability to schedule a pod referencing a malicious checkpoint image. Enforce Pod Security Standards: Apply the restricted or baseline Pod Security Standard at the namespace level using Pod Security Admission. While this does not directly block checkpoint restore, it limits the security contexts an attacker can request, reducing the impact if combined with other controls. Restrict container image registries: Use an image policy (e.g., OpenShift image policy, Kyverno, or OPA Gatekeeper) to allowlist trusted registries only. This prevents pods from pulling malicious checkpoint images hosted on attacker-controlled registries. Identify and remediate previously restored containers: If checkpoint restore has been used with images from untrusted sources, stop, delete, and recreate those containers. The restored process state may not match the intended security context.