A trust‑boundary flaw in CRI‑O’s sandbox state persistence allows an attacker who can influence pod metadata to overwrite CRI‑O’s own reserved sandbox bookkeeping. Once CRI‑O reloads the altered sandbox after a restart, a container later recreated in the same sandbox may expose the host‑side runtime‑management socket inside the container, effectively leaking a privileged resource and enabling container escape. The weakness is classified as CWE‑501, indicating information exposure through improper handling of resource ownership.

The vulnerability affects Red Hat OpenShift Container Platform 4. No specific affected sub‑versions are listed, so all current releases of this product are potentially at risk until a vendor fix is released.

The CVSS score of 7.8 ranks it as high‑severity, reflecting the possibility of host compromise. EPSS is not available, so the exploitation probability remains uncertain, although the lack of KEV listing suggests no widespread exploitation has been reported yet. The likely attack vector requires the attacker to be able to create or update pods with custom annotations, and then trigger a CRI‑O restart or node reboot to reload the tampered sandbox. Once the sandbox is reloaded, the attacker can mount the host‑side runtime socket into a new container, achieving privilege escalation from within the container to the host.