CVE-2026-62146: Cri-o: cri-o: sandbox state poisoning via pod annotations may expose runtime socket
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.
Other sources
A trust-boundary flaw in CRI-O's sandbox state persistence allows attacker-influenced pod metadata to overwrite CRI-O's own reserved sandbox bookkeeping; once reloaded as trusted after a restart, a later container recreate in that sandbox can expose a host-side runtime-management resource inside the container, enabling container escape.
— MITRE
Affected Software
Event History
Frequently Asked Questions
Which environments are exposed to this issue?
CRI-O environments are exposed when an attacker can create a pod and can cause or wait for a CRI-O restart or node reboot followed by recreation of a container in the same sandbox. The pod does not need to be privileged and does not require hostPath or a custom RuntimeClass.
What conditions are required for exploitation?
An attacker needs permission to create a pod with crafted annotations, plus a subsequent runtime restart or node reboot so the poisoned sandbox state is reloaded. A later container recreation in that sandbox is then needed for the host-side runtime-management resource to be mounted into the container.
What is the likely impact if exploitation succeeds?
The affected container may gain access to a host-side runtime-management resource. This may allow it to direct the runtime to operate with host privileges, leading to container escape and full node compromise.