CVE-2024-8676: CRI-O Privilege Escalation Vulnerability

CVE-2024-8676 Overview

CVE-2024-8676 is an authorization flaw in CRI-O, the Kubernetes Container Runtime Interface implementation for Open Container Initiative (OCI) containers. When CRI-O restores a container from a checkpoint archive, it reconstructs mount points from the archive rather than from the pod specification. As a result, the pod-spec validations that normally confirm a pod is permitted to access requested host mounts are bypassed. A user with access to the kubelet or CRI-O socket can invoke the restore endpoint and instantiate a pod with host mounts it was never authorized to use. The flaw is tracked under CWE-285: Improper Authorization.

Critical Impact

An attacker with kubelet or CRI-O socket access can restore a checkpointed container whose mounts grant unauthorized access to host filesystem paths, breaking the pod-spec mount validation boundary.

Affected Products

• CRI-O container runtime (checkpoint/restore feature)
• Red Hat OpenShift Container Platform (multiple 4.x streams referenced in Red Hat advisories)
• Kubernetes clusters using CRI-O as the container runtime with checkpoint/restore enabled

Discovery Timeline

• 2024-11-26 - CVE-2024-8676 published to NVD
• 2026-04-15 - Last updated in NVD database

Technical Details for CVE-2024-8676

Vulnerability Analysis

CRI-O supports container checkpoint and restore using CRIU (Checkpoint/Restore In Userspace). A checkpoint archive captures the running state of a container, including its mount configuration. When the restore endpoint is invoked, CRI-O reconstructs the container using the mounts serialized in the archive instead of revalidating them against the live pod specification.

The pod-spec validation pipeline normally enforces that a pod may only mount host paths it has been explicitly granted via volume declarations and security policy. Because the restore path skips this pipeline, an attacker can supply a crafted checkpoint archive whose mount list references arbitrary host directories. The resulting restored container runs with those mounts despite the requesting pod spec never having declared them.

Root Cause

The root cause is improper authorization on the restore code path. CRI-O treats the checkpoint archive as the source of truth for mount configuration during restore, rather than re-running pod admission and mount validation against the requesting pod object. This violates the principle that runtime decisions must be re-validated against the current pod spec at each lifecycle transition.

Attack Vector

Exploitation requires access to the kubelet API or the CRI-O Unix socket (/var/run/crio/crio.sock). An attacker with such access — for example, a compromised node-local component, a privileged DaemonSet, or a user with nodes/proxy permissions — calls the restore endpoint with a checkpoint archive that contains attacker-controlled mount entries. CRI-O reconstructs the container with those mounts, providing read or write access to host paths that pod admission would have rejected. The attack does not require user interaction and is performed over the runtime socket interface.

No verified public proof-of-concept code is available. See the Red Hat CVE Analysis CVE-2024-8676 and Red Hat Bug Report #2313842 for upstream technical detail.

Detection Methods for CVE-2024-8676

Indicators of Compromise

• Unexpected calls to the CRI-O RestoreContainer or checkpoint-restore API on cluster nodes.
• Containers running with host mounts that are not declared in the corresponding pod spec or are absent from the API server's pod object.
• Checkpoint archive files (.tar artifacts produced by CRIU) appearing on nodes outside of approved backup or migration workflows.
• Audit log entries showing access to /var/run/crio/crio.sock from workloads that should not interact with the runtime socket.

Detection Strategies

• Compare live container mount namespaces against the declared volumeMounts and volumes of the owning pod; flag divergences.
• Monitor Kubernetes audit logs for use of the checkpoint and restore endpoints, especially from non-administrative service accounts.
• Alert on container processes whose mount table references sensitive host paths such as /etc, /var/lib/kubelet, /root, or /var/run/secrets.
• Track creation and ingestion of CRIU checkpoint archives on worker nodes and correlate with the originating identity.

Monitoring Recommendations

• Enable Kubernetes API audit logging at the RequestResponse level for pods/checkpoint and any restore subresource calls.
• Forward CRI-O daemon logs (journalctl -u crio) to a central log store and alert on restore operations.
• Baseline which workloads legitimately use checkpoint/restore and treat any deviation as suspicious.

How to Mitigate CVE-2024-8676

Immediate Actions Required

• Apply the CRI-O updates shipped in the Red Hat advisories listed below to all cluster nodes.
• Restrict access to the kubelet API and the CRI-O Unix socket to trusted node-local components only.
• Disable the container checkpoint/restore feature on clusters that do not require it, including the relevant Kubernetes feature gate.
• Audit RBAC for any subject with nodes/proxy, pods/exec, or direct node access and remove unnecessary grants.

Patch Information

Fixed CRI-O packages are distributed through Red Hat advisories including RHBA-2024:10826, RHSA-2025:0648, RHSA-2025:1908, RHSA-2025:3297, RHSA-2025:4211, and RHSA-2025:9765. The fix revalidates mounts against the requesting pod spec rather than trusting the checkpoint archive. Refer to the Red Hat CVE Analysis CVE-2024-8676 for the complete list of fixed package versions across OpenShift streams.

Workarounds

• Disable the ContainerCheckpoint feature gate on the kubelet and kube-apiserver until patched CRI-O packages are deployed.
• Enforce a PodSecurity admission policy at the restricted level to prevent privileged pods from being scheduled adjacent to the runtime socket.
• Use a Linux Security Module policy (SELinux or AppArmor) to restrict which processes may open /var/run/crio/crio.sock.

# Disable the checkpoint feature gate on the kubelet (example)
# /etc/kubernetes/kubelet.conf or kubelet systemd drop-in
--feature-gates=ContainerCheckpoint=false

# Verify the CRI-O socket is restricted to root and the kubelet group
ls -l /var/run/crio/crio.sock
chmod 0660 /var/run/crio/crio.sock
chown root:crio /var/run/crio/crio.sock

# Confirm the installed CRI-O version after patching
crio version