A vulnerability was found in CRI-O, where it can be requested to take a checkpoint archive of a container and later be asked to restore it. When it does that restoration, it attempts to restore the mounts from the restore archive instead of the pod request. As a result, the validations run on the pod spec, verifying that the pod has access to the mounts it specifies are not applicable to a restored container. This flaw allows a malicious user to trick CRI-O into restoring a pod that doesn't have access to host mounts. The user needs access to the kubelet or cri-o socket to call the restore endpoint and trigger the restore.
Workaround:
The product does not perform or incorrectly performs an authorization check when an actor attempts to access a resource or perform an action.
Link | Tags |
---|---|
https://access.redhat.com/errata/RHBA-2024:10826 | vendor advisory |
https://access.redhat.com/errata/RHSA-2025:0648 | vendor advisory |
https://access.redhat.com/errata/RHSA-2025:1908 | vendor advisory |
https://access.redhat.com/errata/RHSA-2025:3297 | vendor advisory |
https://access.redhat.com/errata/RHSA-2025:4211 | vendor advisory |
https://access.redhat.com/security/cve/CVE-2024-8676 | vdb entry |
https://bugzilla.redhat.com/show_bug.cgi?id=2313842 | issue tracking |