High priorityDisclosed

Advisory · CVE-2026-15801

CRI-O checkpoint restore can be abused for host filesystem operations

CRI-O's container checkpoint/restore feature validates restore metadata insufficiently, so a privileged user restoring from crafted checkpoint content can perform unintended operations on the host filesystem. The feature is not enabled by default.

Advisory published September 21, 2026Independent summary
Vendor
Red Hat
Product
CRI-O
Identifier / CWE
CVE-2026-15801
CWE-22
Action timing
Immediate
ELI5

Explain it like I’m five

CRI-O lets you freeze a running container and bring it back later, like saving a game. When it unpacks the saved game, it does not check the labels on the box carefully enough. Someone who can feed it a tampered save file can make it touch files outside the container, on the actual machine.

SIMPLIFIED_ATTACK_PATH04 STEPS
  1. 01Feature enabled

    The cluster runs CRI-O with container checkpoint and restore explicitly enabled, which is not the default.

  2. 02Crafted checkpoint

    A privileged user prepares a checkpoint archive whose restore metadata describes paths outside the container.

  3. 03Restore triggered

    The user triggers a container restore from the untrusted checkpoint content.

  4. 04Host filesystem touched

    CRI-O performs filesystem operations derived from the unvalidated metadata on the host, where node-level impact is possible.

What happened

Red Hat disclosed CVE-2026-15801, rated High at CVSS 8.0, in CRI-O’s container checkpoint and restore feature as shipped in Red Hat OpenShift Container Platform 4. When CRI-O is configured to restore containers from checkpoint archives, insufficient validation of restore metadata may allow a user with sufficient privileges to perform unintended operations on the host filesystem.

Red Hat classifies practical exploitability as Moderate: the checkpoint/restore feature is not enabled by default and requires explicit configuration, and exploitation requires the ability to initiate a restore using attacker-influenced checkpoint content, which in typical OpenShift deployments implies highly privileged access to node-level interfaces such as the kubelet or the CRI-O socket.

What to do

  1. Determine whether container checkpoint and restore is enabled on any nodes. Unless it is explicitly required, leave it disabled.
  2. Restrict permissions to create workloads and to access node-level container runtime interfaces (kubelet, CRI-O socket) to trusted administrators only.
  3. Never restore containers from untrusted or unverified checkpoint sources.
  4. Review node-level logs for unexpected restore operations or filesystem activity outside expected paths.
  5. Watch for the forthcoming CRI-O/OpenShift security updates and apply them once released.

Management note

This is a high-severity path from a privileged user into the host filesystem, but only where a non-default feature is switched on. The practical task is small: confirm the feature is off where it is not needed, tighten who can reach runtime interfaces, and stay ready to patch when Red Hat ships the fix.