Loading story…
CVE-2026-92574 (CVSS 8.8) affects CRI-O checkpoint restore and can let an attacker authorized to create pods restore a malicious checkpoint whose process retains its original Linux security state instead of receiving the destination pod's security context. Preserved state may include credentials, capabilities, no_new_privs, seccomp filters, namespaces, and other execution attributes, allowing effective kernel restrictions to diverge from approved Kubernetes YAML policy. The issue affects CRI-O 1.34 and later and Red Hat OpenShift Container Platform 4.17 and later where checkpoint restore is enabled; no active exploitation has been confirmed.
Checkpoint archives created through CRIU should be treated as privileged, security-sensitive artifacts because they can encapsulate a process's full runtime state. Organizations should disable checkpoint restore where it is not required, restrict pod creation and checkpoint-restore permissions, accept checkpoint images only from trusted and verified registries, and validate effective post-restore credentials, capabilities, and seccomp policy. Administrators should deploy vendor-provided fixed CRI-O builds once available; comparable containerd restore functionality has been disabled by default where destination-policy enforcement could not be assured.
See affected versions and whether adversaries are exploiting it.
3 events from the most recent confirmed update back to the earliest known activity.
Earlier in September 2026, a containerd advisory described a comparable checkpoint-restoration policy-enforcement risk. Containerd disabled one restore path by default because it could not guarantee that destination policy would be enforced.
Fixes for CVE-2026-92574 were applied to the CRI-O 1.34.x, 1.35.x, and 1.36.x branches, but the fixed builds had not yet been released. Anticipated fixed versions were identified as 1.34.14, 1.35.9, and 1.36.6.
CVE-2026-92574 was documented as a CRI-O checkpoint-restore flaw in which malicious checkpoint data can retain credentials, capabilities, no_new_privs, and seccomp state rather than applying the destination Kubernetes pod security context. Exploitation requires permission to create pods and enabled checkpoint restoration.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
See whether adversaries are exploiting this yet, and where the affected versions run in your environment.
6 references tracked. Mallory keeps watching after this page renders.
linuxsecurity.com
Open sourcelinuxsecurity.com
Open sourcelinuxsecurity.com
Open sourcelinuxsecurity.com
Open sourcelinuxsecurity.com
Open sourcethreataft.com
Open sourceMap indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
Red Hat released an **Important** security update for OpenShift Container Platform (OCP) 4.18.2 that fixes `CVE-2024-8676`, a CRI-O flaw allowing a checkpoint restore for a pod in one namespace to be triggered from another namespace. The cross-namespace action can violate pod security contexts, creating a container-isolation and authorization risk; Red Hat also issued remediation advisories for affected OCP 4.15, 4.16, 4.17, and 4.18 releases. The OCP 4.18.2 advisory, `RHSA-2025:1908`, also resolves `CVE-2024-11218`, a Podman/Buildah race condition that could enable container escape while building a malicious Containerfile with `--jobs=2`. Red Hat advised OCP 4.18 customers to update packages and accompanying images through their supported release channel across RHEL 8 and RHEL 9 deployments on x86_64, IBM Power, IBM Z/LinuxONE, and ARM64.
Aug 27, 2026
The containerd project released patches for five vulnerabilities in its CRI and image-handling components, including three **critical** flaws tracked as `CVE-2026-50195`, `CVE-2026-53488`, and `CVE-2026-53492`, alongside `CVE-2026-53489` and `CVE-2026-47262`. According to the project’s disclosure and an AWS security bulletin, the bugs could let attackers poison a node’s local image cache with crafted checkpoint images, pass unvalidated image labels that may lead to arbitrary host command execution through label-consuming plugins, and abuse untrusted CDI annotations during checkpoint restore to bypass Kubernetes device allocation controls. The remaining issues include a **high-severity** arbitrary host file-read path through `kubectl logs` by restoring a symlinked `container.log` from a checkpoint image, and a **moderate** denial-of-service flaw that can exhaust memory and crash the `containerd` process. Fixes are available in containerd `2.3.2`, `2.2.5`, and `2.1.9` for all five vulnerabilities, while versions `2.0.10` and `1.7.33` address `CVE-2026-53488` and `CVE-2026-47262`; maintainers urged immediate upgrades and said containers restored from untrusted checkpoints may need to be recreated to remove smuggled CDI configuration tied to `CVE-2026-53492`.
Jul 1, 2026
Red Hat disclosed **`CVE-2026-73269`**, a critical privilege-escalation flaw in the `cluster-curator-controller` component used by **OpenShift Multicluster Engine for Kubernetes**. The bug allows a tenant with only namespace-level access to create a crafted `ClusterCurator` resource whose `metadata.name` differs from `metadata.namespace`, triggering the controller to create a cluster-scoped `ClusterRoleBinding` and, in some cases, a `RoleBinding` in an arbitrary namespace. Those bindings can attach the tenant’s namespace-local `cluster-installer` service account to the powerful curator role, effectively breaking namespace isolation. Successful exploitation can elevate a local tenant to **cluster-wide privileges**, including access to and manipulation of secrets, management of cluster actions, and deletion of hosted clusters or node pools. The issue carries a **CVSS 3.1 score of 9.9** and affects `multicluster-engine/cluster-curator-controller-rhel9`. Red Hat advised organizations to apply vendor fixes and reduce exposure by restricting creation of `ClusterCurator` resources through RBAC, enforcing matching `metadata.name` and `metadata.namespace` with an admission controller, and reviewing permissions that allow creation of cluster-scoped resources.
Aug 13, 2026