CVE Alert: CVE-2026-92574 – Red Hat

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.

**Risk verdict:** High-impact but currently conditional risk; urgent action is warranted for clusters with checkpoint restore enabled, although KEV, SSVC exploitation, PoC and EPSS status are not provided.

A permitted pod creator could introduce process state that defeats the destination container’s intended security controls, enabling credential, capability and syscall-policy abuse. The realistic objectives are workload takeover, sensitive-data access, disruption, and escalation within the cluster; host compromise is not established by the supplied information.

Most likely attack path

Network-reachable Kubernetes API access with low complexity, no user interaction and low privileges is sufficient, but the attacker must be able to create a pod referencing a malicious checkpoint and restore support must be active. Scope is unchanged, so the direct boundary crossed is the container security context; lateral movement depends on service-account permissions, mounted secrets, network policy and workload connectivity.

OpenShift or standalone CRI-O environments using experimental checkpoint/restore, especially shared clusters where developers or automation can create workloads. Clusters using only standard container launch paths are materially less exposed.

Audit pod creation and restore-related API activity by user and service account.

Alert on checkpoint images from unapproved registries or unusual image digests.

Review restored-process security state against the pod specification.

Hunt for unexpected capabilities, credentials, seccomp changes or `no_new_privs` discrepancies.

Investigate newly created privileged-looking workloads and anomalous east-west traffic.

Mitigation and prioritisation

Apply the fixed platform update as soon as released; treat interim exposure as high priority.

If unnecessary, disable checkpoint/restore and restart CRI-O.

Restrict workload-creation RBAC and allowlist trusted image registries.

Enforce baseline or restricted Pod Security Standards as defence in depth.

Recreate any containers restored from untrusted images; confirm change impact in staging.

A considerable amount of time and effort goes into maintaining this website, creating backend automation and creating new features and content for you to make actionable intelligence decisions. Everyone that supports the site helps enable new functionality.

If you like the site, please support us on Patreon or Buy Me A Coffee using the buttons below.