GCP-2026-061
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
AI Analysis
Technical Summary
The vulnerability (GHSA-p7v4-vr35-mj6f, CVE pending) in containerd's CRI implementation allows a container restored from an untrusted checkpoint through the CreateContainer API to bypass the destination security context, executing with elevated privileges. This is due to CRIU restoring process credentials, Linux capabilities, no_new_privs, and seccomp state directly from checkpoint data rather than enforcing the destination CRI ContainerConfig. An attacker with the ability to run a container with a crafted checkpoint image can execute processes as root with full capabilities and no seccomp filters despite restrictive security policies. Containerd's CRI status reporting masks this discrepancy by reflecting the requested configuration rather than the actual restored state. GKE clusters are not vulnerable by default because they do not include the CRIU tool, and standard container creation operations remain unaffected. In containerd versions 2.3.4 and later or 2.2.7 and later, implicit restore is disabled by default via the enable_experimental_restore_via_create option, which can be manually re-enabled but leaves the vulnerability present. Version 2.4 will remove this codepath in favor of an explicit Pod-level restore API.
Potential 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.
Mitigation Recommendations
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.
GCP-2026-061
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
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
The vulnerability (GHSA-p7v4-vr35-mj6f, CVE pending) in containerd's CRI implementation allows a container restored from an untrusted checkpoint through the CreateContainer API to bypass the destination security context, executing with elevated privileges. This is due to CRIU restoring process credentials, Linux capabilities, no_new_privs, and seccomp state directly from checkpoint data rather than enforcing the destination CRI ContainerConfig. An attacker with the ability to run a container with a crafted checkpoint image can execute processes as root with full capabilities and no seccomp filters despite restrictive security policies. Containerd's CRI status reporting masks this discrepancy by reflecting the requested configuration rather than the actual restored state. GKE clusters are not vulnerable by default because they do not include the CRIU tool, and standard container creation operations remain unaffected. In containerd versions 2.3.4 and later or 2.2.7 and later, implicit restore is disabled by default via the enable_experimental_restore_via_create option, which can be manually re-enabled but leaves the vulnerability present. Version 2.4 will remove this codepath in favor of an explicit Pod-level restore API.
Potential 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.
Mitigation Recommendations
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.
Technical Details
- Classification
- {"confidence":0.3,"severitySource":"default","classifier":"rss-v2"}
- Article Source
- {"url":"https://docs.cloud.google.com/kubernetes-engine/security-bulletins#gcp-2026-061","fetched":true,"fetchedAt":"2026-09-09T19:48:42.536Z","wordCount":93795}
Threat ID: 6aa1b81aacd9273b49c8285c
Added to database: 09/09/2026, 19:48:42 UTC
Last enriched: 09/09/2026, 19:48:53 UTC
Last updated: 09/10/2026, 01:47:30 UTC
Views: 10
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
External Links
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.