Recommended Free Tools
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
In the affected containerd CRI checkpoint-restore path, a restrictive destination Pod or CRI configuration does not necessarily become the restored process’s effective security state. CRIU restores security attributes from the checkpoint, while containerd reports the requested configuration in CRI status. The issue requires Linux, CRI checkpoint restore, and an attacker able to run a container from a crafted checkpoint image; ordinary container creation is not the vulnerable route described by the containerd advisory.
Why destination policy can differ from process state
A restore reconstructs a process from saved checkpoint data. In the affected path, containerd says CRIU restores process credentials, Linux capabilities, no_new_privs, and seccomp state from that data rather than enforcing the destination CRI ContainerConfig.
As a result, a crafted checkpoint image could resume with root credentials, full capabilities, and no enforced seccomp filters even when the orchestrator requested more restrictive settings. The destination configuration expresses intent; it is not proof of the restored process’s effective state.
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →There is also a visibility problem: containerd reports the requested configuration in CRI status, not the actual restored process state. A status view can therefore appear consistent with the Pod specification while concealing the discrepancy in the running process.
#1 Best Overall
When the vulnerability applies
The containerd advisory rates this issue Critical. That rating describes severity, not how many clusters are exposed. The affected conditions are specific:
- The system is Linux.
- Containerd’s CRI checkpoint-restore path is in use.
- An attacker can run a container using a crafted checkpoint image.
The advisory says users who do not use CRI checkpoint restore are not affected. Google separately says standard container creation in GKE Standard and GKE Autopilot remains unaffected; that statement concerns standard creation, not every possible restore configuration.
Affected containerd versions and the restore-path change
| Containerd version | Advisory status | What operators should know |
|---|---|---|
>= 2.1.0 < 2.2.7 |
Affected | There is no configuration option to disable this restore path on unpatched versions. |
2.2.7 |
Patched release | Checkpoint restore via CreateContainer is disabled by default. |
>= 2.3.0 < 2.3.4 |
Affected | There is no configuration option to disable this restore path on unpatched versions. |
2.3.4 |
Patched release | Checkpoint restore via CreateContainer is disabled by default. |
2.4.0 |
Feature removed | The restore feature is removed. |
These ranges and release behaviors are from the containerd project advisory. Re-enabling restore through CreateContainer on 2.2.7 or 2.3.4 leaves the vulnerability present; disabling it by default is not a fix if an operator turns it back on.
What to do if untrusted checkpoints may have been restored
- Identify the actual runtime version and restore path. Check the containerd version used by the affected Linux nodes and determine whether CRI checkpoint restore through
CreateContaineris enabled or has been re-enabled. For managed Kubernetes, use the cluster’s actual runtime version and the provider’s bulletin to determine the applicable update. - Stop, delete, and recreate affected restored containers. The containerd advisory specifically says to stop and delete containers restored from untrusted checkpoints, then recreate them. Do not treat their reported CRI configuration as proof that the requested restrictions took effect.
- Move to a fixed runtime release or later supported provider build. The relevant upstream fixed releases are 2.2.7 and 2.3.4, with the feature removed in 2.4.0. Confirm how the provider packages and backports containerd rather than assuming a Kubernetes version alone establishes the runtime fix.
- Restrict who can create containers or Pods. Google recommends limiting container-creation permissions, validating image registries, and monitoring node logs and runtime events. Apply those controls to the identities and workloads able to introduce checkpoint images.
How to inspect a restored process
Because CRI status reflects requested configuration, inspect the live process independently when investigating a restored container. On the node, use the process ID for the container’s process:
grep -E 'NoNewPrivs|Seccomp|CapEff' /proc/<pid>/statusCompare those fields with the security settings requested for that Pod. NoNewPrivs, Seccomp, and CapEff expose relevant parts of process state; this check is an operational diagnostic, not a guarantee that every security control is represented by those three fields. Obtain the correct PID for the container and interpret the values against the policy that was intended to apply.
Other checkpoint restore risks are related, but distinct
Separate containerd advisories describe other ways checkpoint artifacts can carry authority across a restore boundary. They are not evidence that every restore has all of these problems, and they do not change the specific process-security issue above.
- A June symlink-following advisory describes a restored
container.logsymlink that could enable arbitrary host-file reads throughkubectl logs. It lists fixes in 2.1.9, 2.2.5, and 2.3.2. - A CDI advisory describes untrusted checkpoint metadata carrying CDI annotations into restoration, potentially bypassing normal Kubernetes resource allocation and device-plugin enforcement when CDI and matching host-spec conditions apply.
- A checkpoint-import advisory describes unvalidated image references poisoning the node-local image cache.
Together, these issues illustrate why a checkpoint should be treated as an input that can affect the node and restored workload, not merely as a passive copy of files.
Free tools Windows power users keep installed
One-click scans. No signup required.
What Kubernetes KEP-5823 would change—and what it would not establish
Kubernetes KEP-5823 proposes explicit Pod-level CheckpointPod and RestorePod CRI operations, kubelet handling, and declarative restore through Pod configuration. It is a proposal; the available project material does not establish that it is currently shipped or identify a release in which it is available.
Best Value
The proposal also treats runtime checkpoint contents and format as opaque to Kubernetes and owned by the runtime/checkpoint mechanism. Explicit Pod-level operations would define an API workflow, but the proposal does not prove that restored process security attributes match destination policy. The process-state boundary still matters.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
