CRI-O EUVD-2026-89789

Exploitation requires the attacker to be able to create or influence a pod's metadata on a CRI-O-managed node (PR:L, e.g. a low-privileged namespace tenant on shared OpenShift infrastructure), so it is not remotely reachable without cluster workload access. The chain further depends on non-trivial sequencing: the poisoned sandbox bookkeeping is only trusted after a CRI-O daemon restart reloads persisted state, and the host-side runtime-management resource is only exposed on a subsequent container recreate within that same sandbox - this restart-then-recreate dependency is the concrete factor captured by AC:H and is the primary limiter on realistic exploitation. There is no user-interaction requirement (UI:N), but the local attack vector, low-but-nonzero privilege requirement, and reliance on a runtime restart substantially narrow the practical attack surface versus the raw 7.8 score.

The CVSS 3.1 vector (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H, 7.8 High) describes a local-vector, high-complexity, low-privilege flaw that nonetheless achieves a scope change with full confidentiality, integrity and availability impact - i.e., a container escape from a low-privileged workload to the host runtime. The high base score is driven by the S:C/C:H/I:H/A:H impact, but AC:H and AV:L meaningfully constrain real-world exploitation: the attacker must already be able to schedule/influence a pod on the target node, must poison CRI-O's sandbox bookkeeping via attacker-influenced pod metadata, and must then have that poisoned state reloaded as trusted after a CRI-O restart before a subsequent container recreate exposes the host-side runtime-management resource. No EPSS score, KEV listing, SSVC decision, or POC indicator was supplied in the input, so exploitation status is 'no public exploit identified at time of analysis.' The absence of KEV/EPSS is not itself an error but does mean there is no evidence of active or automatable exploitation; the multi-step, restart-dependent nature makes opportunistic mass exploitation unlikely. Net: a genuinely serious container-escape primitive worth prioritizing on OpenShift/CRI-O fleets, but its practical exploitability is gated by the restart-reload sequencing captured in AC:H, so it is not a drop-everything remote-unauth issue.

A tenant who can create pods on a shared OpenShift/CRI-O node crafts pod metadata whose fields collide with CRI-O's own reserved sandbox bookkeeping, poisoning the persisted sandbox state. After a CRI-O restart the tainted state is reloaded and trusted, and when a container is later recreated in that sandbox a host-side runtime-management resource is mounted/exposed inside the container, giving the attacker a path off the container onto the host. No public exploit code is identified at time of analysis, and success depends on the local, high-complexity restart-and-recreate sequence.