High [CVE-2026-92574] CRI-O checkpoint restore bypasses destination security context
This high-severity Red Hat Linux advisory covers CVE-2026-92574; related products: Red Hat OpenShift Container Platform 4.
Aggregated and source-linked by VulniPulse. Data sources, validation and limitations.
VulniPulse record published Record updated
Android app · Google Play
Monitor future Red Hat Linux CVEs from your phone.
Choose a whole vendor or a precise platform, then receive matching security advisories by phone notification, email, or both. Coverage follows 32 official vendor sources and 160+ reviewed platform categories.
Summary
CRI-O checkpoint restore bypasses destination security context. Red Hat rates this important (CVSS 8.8).
Weakness: CWE-250.
Affected product named by the advisory: Red Hat OpenShift Container Platform 4.
- 1.34
- 4.17
Official advisory · high-confidence parse· fetched 9 days ago·verify at source
Fixed versions
No fixed release is recorded yet. That does not prove no patch exists — confirm against the vendor advisory.
Official advisory · high-confidence parse· fetched 9 days ago·verify at source
Mitigation checklist
- 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.
Official advisory · high-confidence parse· fetched 9 days ago·verify at source
Discussion(0)
No comments yet. Share field notes, upgrade gotchas, or questions — verify against the vendor advisory before acting on community advice.
Sign in to join the discussion.