Fedora Account System
Red Hat Associate
Red Hat Customer
A flaw was discovered in CRI-O's checkpoint and restore capability. If a container is restored from a checkpoint archive, CRI-O does not adequately validate the restore metadata. A sufficiently privileged user could therefore cause unintended host filesystem activity during the restore process. This behavior is only reachable when checkpoint and restore has been explicitly enabled; it is not active in the default CRI-O/OpenShift configuration. Exploitation also depends on the attacker being able to initiate a restore operation using checkpoint data that they control or supply.
CVSS Justification for OpenShift AV:N — Exploitation is triggered through the Kubernetes/CRI API over the network (e.g., creating a pod/container with a checkpoint image), not only via direct local shell access. AC:H — Container checkpoint/restore is not enabled by default in CRI-O/OpenShift and requires explicit --checkpoint-restore=true (or equivalent feature enablement). PR:H — Triggering restore with attacker-controlled checkpoint content requires highly privileged access (kubelet/CRI-O socket or equivalent node/cluster-level privilege). UI:N — No end-user interaction is required once the attacker has the necessary privileges and a malicious checkpoint archive. S:U — In typical OpenShift deployments, the high privilege bar and non-default feature reduce practical cross-security-boundary impact despite host filesystem write potential. C:H — Successful exploitation can read sensitive host files via arbitrary write paths (e.g., SSH keys, credentials, system config). I:H — The flaw allows arbitrary file write as root on the node (e.g., cron, authorized_keys, profile.d), enabling full node compromise. A:N — The primary impact is unauthorized write/integrity abuse; availability disruption is possible but secondary and not the main attack path.