CVE-2026-92574: CRI-O Privilege Escalation Vulnerability

CVE-2026-92574 Overview

CVE-2026-92574 is a privilege escalation vulnerability in the Container Runtime Interface for OCI (CRI-O) checkpoint restore feature. When a user restores a pod from a malicious checkpointed container image, the restored process may retain credentials, Linux capabilities, no_new_privs, and seccomp state from the original checkpoint. CRI-O fails to enforce the destination pod's Kubernetes security context, allowing execution across the container security boundary with elevated privileges. Upstream CRI-O versions 1.34 and later are affected, along with Red Hat OpenShift Container Platform (OCP) 4.17 and later downstream releases. The weakness is categorized under [CWE-250: Execution with Unnecessary Privileges].

Critical Impact
Authenticated users with pod creation rights can restore malicious checkpoints to gain elevated Linux capabilities, bypass seccomp filters, and escape the intended container security context.

Affected Products

CRI-O upstream versions 1.34 and later
Red Hat OpenShift Container Platform (OCP) 4.17 and later
Kubernetes clusters with CRI-O checkpoint restore enabled

Discovery Timeline

2026-09-21 - CVE-2026-92574 published to NVD
2026-09-22 - Last updated in NVD database

Technical Details for CVE-2026-92574

Vulnerability Analysis

CRI-O implements checkpoint and restore functionality using Checkpoint/Restore in Userspace (CRIU) to serialize a running container's process state to disk. On restore, the runtime should reconcile the checkpointed state with the destination pod's Kubernetes securityContext. This reconciliation does not occur correctly for several privilege-relevant attributes.

The restored container process retains its original UID and GID credentials, effective Linux capability set, no_new_privs flag value, and seccomp filter configuration from the source checkpoint. If an attacker crafts a checkpoint image where the original process ran with elevated capabilities such as CAP_SYS_ADMIN, or with a permissive seccomp profile, those attributes persist after restore even when the destination pod specification requests a restricted profile.

The result is a security context desynchronization. Cluster administrators who apply pod security standards, seccomp defaults, or capability drops through admission controllers cannot rely on those controls being enforced against restored workloads.

Root Cause

The root cause is missing enforcement logic in the CRI-O restore code path. The runtime treats the serialized process state as authoritative rather than applying the destination Kubernetes security context on top of the restored process. This aligns with [CWE-250], where a process executes with more privileges than required for its function.

Attack Vector

Exploitation requires an authenticated principal with permission to create pods that reference a checkpoint image, and requires the cluster to have checkpoint restore functionality available. The attacker builds or supplies a malicious checkpoint whose process holds elevated capabilities, disabled no_new_privs, permissive seccomp state, or privileged UID mappings. Creating a pod from that checkpoint triggers restore under CRI-O 1.34 or later, and the resulting container runs with the attacker-controlled security attributes despite any restrictive securityContext on the destination pod.

No verified public exploit code is available. See the Red Hat CVE-2026-92574 Advisory and Red Hat Bug Report #2535436 for vendor details.

Detection Methods for CVE-2026-92574

Indicators of Compromise

Pod creation events referencing checkpoint images from untrusted registries or unexpected image paths.
Running containers whose effective capability set, seccomp mode, or UID differs from the applied pod securityContext.
CRI-O logs showing RestoreContainer or CRIU restore operations from user-supplied checkpoint archives.
Kubernetes audit log entries where create pods requests include checkpointPath or annotations referencing restored container images.

Detection Strategies

Compare the runtime capability set and seccomp state of each container against the pod specification submitted to the API server, alerting on divergence.
Monitor Kubernetes audit logs for pod creation requests that use checkpoint restore, particularly from non-administrative service accounts.
Enforce admission policies that reject pods sourcing images from checkpoint archives outside an approved allowlist.

Monitoring Recommendations

Ingest CRI-O and kubelet logs into a centralized analytics platform and alert on restore operations correlated with capability escalation.
Track process-level telemetry for containers running with CAP_SYS_ADMIN, CAP_NET_ADMIN, or no_new_privs=0 that were instantiated through restore paths.
Baseline expected checkpoint restore activity per namespace and flag deviations.

How to Mitigate CVE-2026-92574

Immediate Actions Required

Disable CRI-O checkpoint restore functionality on clusters where it is not required for operational use cases.
Restrict pods/create RBAC permissions and remove the ability to reference arbitrary checkpoint images from non-administrative users and service accounts.
Apply Pod Security Admission at the restricted level to limit which principals can request elevated capabilities or privileged security contexts.
Audit existing workloads for containers whose runtime state does not match their declared securityContext.

Patch Information

Red Hat has confirmed that fixes have been applied to supported CRI-O branches but are not yet released as of the last NVD update on 2026-09-22. Track the Red Hat CVE-2026-92574 Advisory for patched package versions for OpenShift Container Platform 4.17 and later. Upstream CRI-O users should monitor the CRI-O 1.34+ release branches for the corresponding fix.

Workarounds

Set enable_criu_support = false in the CRI-O configuration to disable checkpoint restore until patches are available.
Use an admission controller such as Kyverno or OPA Gatekeeper to block pod specifications that reference checkpoint images or restore annotations.
Isolate namespaces that require checkpoint restore onto dedicated node pools with additional monitoring and network segmentation.
Enforce cluster-wide seccomp defaults through the kubelet --seccomp-default flag so restored containers are subject to a baseline profile.

bash

# Disable checkpoint restore in CRI-O configuration
# /etc/crio/crio.conf.d/10-disable-checkpoint.conf
[crio.runtime]
enable_criu_support = false

# Restart the CRI-O service to apply
sudo systemctl restart crio

# Verify checkpoint restore is disabled
crio-status config | grep -i criu