GCP-2026-061
Source GCP Kubernetes Security
Rated by Threat Radar
Data as of 09/09/2026, 20:04:38 UTC
What to do
AI-suggested
No immediate action is required for default GKE clusters as they do not include the CRIU binary. For environments with custom CRIU installations on containerd nodes (versions 2.3.4 and later or 2.2.7 and later), ensure the enable_experimental_restore_via_create configuration option is set to false to disable the vulnerable implicit restore feature. Re-create any containers restored from untrusted checkpoints by stopping, deleting, and recreating them. Audit containerd logs for implicit restore activity using search strings like "Found checkpoint of container", "Prepared for restore", or "Restored container successfully". Restrict Kubernetes Pod creation permissions to trusted users and service accounts via RBAC. Enforce the use of trusted image registries for Pod images. Prepare to adopt the explicit Pod-level Checkpoint or Restore APIs when available in future Kubernetes releases (KEP-5823). Avoid manually re-enabling the experimental restore feature as it leaves the vulnerability present.
Description
Published: 2026-09-09 Reference: GHSA-p7v4-vr35-mj6f Description Severity A security vulnerability GHSA-p7v4-vr35-mj6f (CVE assignment pending) in containerd's CRI implementation allows a container restored from an untrusted checkpoint through the CreateContainer API to bypass the destination security context and execute with elevated privileges. When restoring a container from a checkpoint archive or annotated OCI image, CRIU restores process credentials, Linux capabilities, no_new_privs , and seccomp state directly from checkpoint data rather than enforcing the destination CRI ContainerConfig . An attacker who can run a container with a crafted checkpoint image can execute processes as the root user with full capabilities and no enforced seccomp filters despite restrictive security policies requested by the orchestrator. Additionally, containerd's CRI status reporting reflects the requested configuration rather than the actual restored process state, masking the privilege discrepancy from orchestrators. GKE clusters are not vulnerable by default. GKE node images do not include the criu tool. Implicit container restore is not supported without criu installed on the node. Standard container creation operations in GKE Standard and GKE Autopilot remain unaffected. GKE Autopilot clusters do not support custom runtime configuration and are not impacted. Additionally, Pod snapshots in GKE do not exercise the vulnerable implicit restore codepath. In updated containerd versions (2.3.4 and later, or 2.2.7 and later), implicit restore is disabled by default through the enable_experimental_restore_via_create configuration option. Version 2.4 of containerd will remove this codepath completely in favor of the explicit Pod-level restore API (KEP-5823). Warning: Administrators can manually re-enable the feature in containerd (2.3.4 and later, or 2.2.7 and later) by setting the enable_experimental_restore_via_create configuration option. However, doing so leaves this vulnerability present because containerd cannot enforce destination security policy while it restores the criu process. What should I do? Because GKE does not include the criu binary on default node images, no immediate cluster upgrades or configuration changes are required for default workloads. If you install custom runtime software or node tools on your nodes that include the criu binary, consider taking the following actions as appropriate for your environment: Re-create existing restored containers: Stop, delete, and re-create any running containers that were restored from untrusted checkpoints. Disable experimental restore (containerd 2.3.4 and later, or 2.2.7 and later): If operating nodes with containerd (2.3.4 and later, or 2.2.7 and later) and custom criu installations, ensure the enable_experimental_restore_via_create configuration option remains set to false in your containerd node configuration. Audit containerd logs: If criu is installed, inspect node logs for implicit restore log entries containing search strings such as "Found checkpoint of container" , "Prepared for restore" , or "Restored container successfully" . Monitor deprecation warnings for containerd: Look for the following deprecation warning event: io.containerd.deprecation/cri-create-container-checkpoint-restore . Restrict Pod creation permissions: Ensure Kubernetes RBAC restricts Pod creation permissions ( create pods ) strictly to trusted users and service accounts. Enforce trusted image registries: Ensure that the values for the Pod's image: field reference verified image repositories. Prepare for KEP-5823: Update operational procedures to rely on explicit Pod-level Checkpoint or Restore APIs after they are available in future Kubernetes releases. Medium
Impact
An attacker able to run containers with crafted checkpoint images can bypass security policies and execute processes as root with full Linux capabilities and no seccomp filtering, potentially leading to privilege escalation within the container environment. The vulnerability also causes containerd to report incorrect status, masking the elevated privileges from orchestrators. However, default GKE clusters are not affected due to the absence of the CRIU tool, and standard container creation operations remain secure.