Fedora Account System
Red Hat Associate
Red Hat Customer
A flaw was found in CRI-O. CRI-O persists reserved internal sandbox metadata alongside untrusted pod-supplied annotations without adequate separation, allowing a crafted pod annotation to overwrite that reserved state before it is saved to disk; after a CRI-O restart or node reboot, this poisoned value is reloaded as trusted and used by a later container recreate in the same sandbox, which can result in a host-side runtime-management resource being bind-mounted into the container. A container that gains access to this resource may be able to direct the runtime to act with host privileges, resulting in container escape and full node compromise. This does not require a privileged pod, hostPath, or a custom RuntimeClass, only the ability to create a pod plus a subsequent runtime restart/recreate.
CVSS Justification: AV:L (Local) — The vulnerable component (CRI-O daemon/socket) isn't network-reachable; exploitation requires a workload already scheduled on the affected node. AC:H (High) — Requires a specific timing condition beyond attacker control: a CRI-O restart/node reboot followed by a container recreate in the same sandbox. PR:L (Low) — Attacker only needs the ability to create a Pod with a crafted annotation, not elevated/admin cluster privileges. UI:N (None) — No action from another user or admin is needed once the pod is created and the restart/recreate condition occurs. S:C (Changed) — The flaw crosses from the container's security scope into the host's, since it exposes a host-level control socket inside the container. C:H (High) — Access to the exposed runtime socket lets an attacker read host/runtime state and other containers' data. I:H (High) — The same socket access allows issuing commands to the container runtime, letting an attacker modify host-managed resources. A:H (High) — Runtime-level control via the socket can be used to disrupt or take down containers/workloads on the node.