CVE-2026-95837: containerd checkpoint restore ignores the pod's security context

01

What the vulnerability does

containerd's CRI plugin can create a container from a checkpoint: an archive or an annotated OCI image that holds a process saved by CRIU. When it does, CRIU restores the process credentials, Linux capabilities, no_new_privs and seccomp state from the checkpoint data. The security context the orchestrator asked for in the CRI ContainerConfig is not applied to the restored process.

So anyone who can run a container from a checkpoint image they crafted can end up with processes running as root, with every capability and no seccomp filter, inside a pod whose spec asked for a non-root user, dropped capabilities and a restrictive profile.

The part that matters most for detection: containerd's CRI status reports the configuration that was requested, not the state of the restored process. The kubelet, admission controllers and anything reading the Kubernetes API see the restrictive settings they asked for.

02

Affected and fixed versions

From the containerd advisory. Only Linux nodes with CRI checkpoint restore available are affected; the advisory states that users not using CRI checkpoint restore are not affected.

• Affected: github.com/containerd/containerd/v2 from 2.1.0 before 2.2.7, and from 2.3.0 before 2.3.4.
• Fixed: 2.2.7 and 2.3.4, which disable checkpoint restore through CreateContainer by default. In 2.4.0 the feature is removed.
• The advisory does not list the 1.7 or 2.0 release lines.
• Not a workaround on unpatched versions: containerd offers no setting there to switch restore through CreateContainer off.

03

Check your nodes

Start with the runtime version on every node; the Kubernetes API reports it. Then, on patched nodes, confirm the restore path is still off, because the fix added an option that turns it back on.

kubectl get nodes -o custom-columns=\
NODE:.metadata.name,\
RUNTIME:.status.nodeInfo.containerRuntimeVersion

# On a node running 2.2.7, 2.3.4 or later:
containerd config dump | grep -E \
  'enable_criu|enable_experimental_restore_via_create'

04

What the API cannot tell you, and what can

Because containerd reports the requested security context, every check that reads the Kubernetes API or the CRI status will say a restored container is fine. The only reliable view is the process itself, as the kernel sees it.

Compare what the pod asked for with what its first process actually holds. Uid 0, a full CapEff mask, NoNewPrivs 0 or Seccomp 0 on a container whose spec asked for a non-root user, dropped capabilities or a seccomp profile is the mismatch this vulnerability produces.

A restore also leaves a trace in process activity: CRIU runs on the node to restore the process. Any runtime sensor that records process executions on nodes, such as Falco, Tetragon or Primod, will show a criu restore that nobody planned, and which pod it created.

# On the node: the container's first process
crictl inspect <container-id> | grep -m1 '"pid"'
grep -E '^(Uid|CapEff|NoNewPrivs|Seccomp):' \
  /proc/<pid>/status

05

Fixing it

Upgrade containerd to 2.2.7, 2.3.4 or later, and leave enable_experimental_restore_via_create off. The advisory also says containers that were restored from untrusted checkpoints should be stopped, deleted and recreated, since the upgrade does not change processes already running.

Until the upgrade lands, the advisory's mitigations are about who can start containers from what: restrict container creation to trusted users, only allow images from registries you control, and use an admission policy to reject images that carry checkpoint data.

06

Where Primod fits

Primod's per-node eBPF sensor records process executions and lineage with the workload they belong to, so an unexpected criu restore and the processes it brought back show up against the pod they ran in. That is evidence of what happened on the node; it does not replace the upgrade.