Checkpoint Restore: Destination Policy Was Never Reapplied

A checkpoint restore can rebuild a process from saved state without passing that state back through the destination’s normal policy translation. When it does, the security context on the Pod spec describes the workload that was approved, and the process on the node is the one that was saved.

That is a boundary problem before it is a vulnerability problem. Kubernetes has one place where policy becomes process state, and it is creation. Restore is a second route to a running process, and nothing on that route decides what wins when saved state and destination policy disagree. Advisories on the restore path in containerd and CRI-O show what crosses when nothing decides. They are evidence for the architecture, and the architecture is the subject.

Two Ways to Create a Process

On the normal path, the process is built from declarations. A Pod spec passes admission, the kubelet hands the runtime a container config, and the runtime turns that config into kernel state: a user and group, a capability set, the no_new_privs flag, a seccomp filter. That translation step is how modern infrastructure architecture turns declared intent into enforced state. Each attribute is policy made concrete, which is why seccomp filters and capability drops eliminate whole classes of exploit only when they are actually attached to the process. Kubernetes documents that allowPrivilegeEscalation directly controls whether no_new_privs is set. The field in the spec is the request. The flag on the running process is the enforcement.

Checkpoint restore does not build a process. It reconstitutes one. CRIU records a running process, including its credentials, capabilities, no_new_privs flag and seccomp state, and restore replays that record. On the path containerd exposed, the restore is triggered inside the ordinary container-create call, by a checkpoint archive or an annotated image. Kubernetes currently supports container restore only through those image annotations, so from admission’s side this is a Pod create with an image reference. Whether it is a restore is decided later, inside the runtime, by what the image contains.

Restore is usually treated as a data operation whose failures show up in the layers above it, the pattern restore design failure documents: the restore completes and the workload is still unusable. This is a different gap. Every layer can pass, and the process can still come back carrying state the destination never approved.

What the Advisories Show About Checkpoint Restore

containerd’s September 1 advisory states the outcome directly. A container restored from an untrusted checkpoint through the create call can run as root with full capabilities and no seccomp filter, despite restrictive policy requested by the orchestrator. It applies where checkpoint restore through CRI is enabled and an attacker can run a container from a crafted checkpoint image. The affected ranges run from 2.1.0 up to, but not including, 2.2.7, and from 2.3.0 up to, but not including, 2.3.4. Those two releases disable the path by default.

The same checkpoint and restore path had already produced three other trust failures in June, according to Google’s GKE security bulletins. Each accepted something the checkpoint supplied.

CRI-O’s CVE-2026-92574 records the same outcome for that runtime: saved credentials, capabilities, no_new_privs and seccomp state can take effect where the destination’s configuration should have.

Precedence Was Never Decided

These are not four bugs in four attributes. Each is the same event: state supplied by an artifact took effect on restore, and the destination’s policy was not applied over it. Nothing adjudicated. The runtime did not weigh the saved credentials against the requested user and pick the saved ones. The translation that would have replaced them never ran. That difference matters. A precedence rule that was chosen can be audited and changed. One that was never made has to be built.

Who has the right to change infrastructure is the question the Control Plane Boundaries stage of the Modern Infrastructure learning path puts at the center, with GitOps, CI/CD, consoles and platform APIs as competing claimants. A restore path is one more claimant, and it arrives with no place in that ordering. It is also a different condition from Policy Intent Drift (#133), where declared and enforced state match and the reason for the rule has expired. On restore, declared and effective state never matched, and nothing compared them.

containerd’s handling shows the shape of it. The June issues were fixed in point releases, the CDI one in 2.1.9, 2.2.5 and 2.3.2, with the restore path left in place. The September issue could not be fixed that way: in the advisory’s own terms, containerd “cannot enforce destination security policy” while it restores the process. So 2.2.7 and 2.3.4 disable the path by default, and 2.4 removes it. That removal was already scheduled. containerd’s release documentation lists restore during CRI create as deprecated in 2.3, released April 30, with removal targeted for 2.4 and the RestorePod API in KEP-5823 named as the replacement. The advisories did not set that timeline. They show why the path cannot be kept safe by patching one attribute at a time.

Status Is Not State

containerd’s advisory adds a second problem. Its CRI status reporting reflects the requested configuration, not the state of the restored process, so an orchestrator reading status sees the destination policy while the process runs the saved one. Google’s bulletin repeats the point. The CRI-O record does not describe status reporting, so the claim belongs to containerd alone.

This is the split Kubernetes requests and limits already draws for CPU and memory: the spec records what was requested, and the kernel enforces what the process holds. The difference here is that the checkpoint restore path can make the two disagree on security attributes while the control plane keeps reporting the request. The evidence has to come from the process. On a node, the NoNewPrivs, Seccomp and CapEff fields in /proc/<pid>/status are what to compare against the security context the Pod asked for.

grep -E 'NoNewPrivs|Seccomp|CapEff' /proc/<pid>/status

These fields reveal the effective process state after restore and can be compared against the Pod’s requested security context.

Where Support Windows Make This Live

Whether the mitigation is available depends on the release line. containerd’s release documentation lists 2.1 as end of life on July 3, 2026. The September advisory’s affected range starts at 2.1.0, and its patched versions are 2.2.7 and 2.3.4, so it lists no fixed 2.1 release. On unpatched versions the advisory says containerd offers no option to disable restore through the create call. Exposure still requires checkpoint restore to be in use, but a support date decides whether turning it off is a configuration change or an upgrade. A support date and an enforcement date are different things, as the Kubernetes 1.37 containerd deadline shows for a different deadline. Version 2.2 is active until November 6, 2026, 2.3 is the LTS release through April 2028, and 2.4 has removed the path.

What Restore Has to Prove Before It Runs

If restore is a second instantiation path, it needs its own proof, because admission cannot supply it. Three things have to be shown. That a restore was requested, deliberately, by someone allowed to request it. That the artifact came from a source the platform trusts. And that the process that came back holds the attributes the destination policy specifies. Google’s bulletin turns the first two into controls: restrict who can create Pods, allow only verified image registries, and watch node logs for restore entries and the runtime’s events for the deprecation warning on restore through create. The third is the one status cannot give you.

The replacement makes the first requirement explicit. Under KEP-5823, which targets alpha in Kubernetes 1.38 and has not shipped, restore is declared on the Pod spec, authorized through a dedicated restore verb, and admitted only if the Pod spec equals a template the kubelet recorded when the checkpoint was taken. That settles the conflict by forbidding divergence between spec and checkpoint. It does not, as the KEP is written, verify the restored process itself: the equality check runs against the recorded object, and the runtime’s checkpoint archive is treated as opaque to Kubernetes. The KEP’s text does not describe checking restored credentials, capabilities, no_new_privs or seccomp state against the spec.

A restore that cannot enforce destination policy should not run. That is the position containerd reached when it disabled the path, and it is the rule any platform allowing restore has to state for itself: who decides what a restored workload may hold, and what is read from the process to prove it.

Additional Resources

About The Architect

R.M.

Senior Solutions Architect with 25+ years of experience in HCI, cloud strategy, and data resilience. As the lead behind Rack2Cloud, I focus on lab-verified guidance for complex enterprise transitions. View Credentials →