CVE-2026-50195 is a critical (CVSS 9.9) flaw in containerd. CRI checkpoint import does not validate image references, so a user who can create pods can poison a node's local image cache. Upgrade to containerd 2.3.2, 2.2.5 or 2.1.9, and review pull policies and who can create pods.
What's affected
- Product: containerd, the container runtime, version 2 lines (Go module
github.com/containerd/containerd/v2). - Affected: 2.1.0 to before 2.1.9, 2.2.0 to before 2.2.5, and 2.3.0 to before 2.3.2.
- Fixed: 2.1.9, 2.2.5 and 2.3.2.
- Weaknesses: CWE-345, insufficient verification of data authenticity, and CWE-829, inclusion of functionality from an untrusted control sphere.
- CVSS 9.9 (critical), vector
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H. The vector shows low privileges are needed. - Published 1 July 2026. Not marked as exploited in CISA KEV.
The attacker needs permission to create pods, so the exposure is highest in shared clusters.
How to check if you're exposed
Check the runtime version on every node.
containerd --version
kubectl get nodes -o wide
The CONTAINER-RUNTIME column of the second command shows the runtime and version per node. Managed Kubernetes services update node images on their own schedule, so read your provider's bulletin for the CVE.
Then check two settings. Who can create pods in each namespace? Do your workloads use imagePullPolicy: IfNotPresent or Never? The advisory says those policies are the ones that trust whatever tag is already on the node.
What to do now
- Upgrade containerd to 2.3.2, 2.2.5 or 2.1.9, or move to a node image from your provider that includes the fix.
- Restrict who may create pods, and in shared clusters use admission policies that limit images to approved registries.
- Where it fits your release process, reference images by digest rather than by mutable tag, so a poisoned tag cannot stand in for the real one.
- Consider the Always pull policy for sensitive workloads, since the advisory ties the risk to IfNotPresent and Never.
- Drain and replace nodes you suspect of running unexpected images, and compare running image digests with the digests you deployed.
Why it matters
Container tags are names, not guarantees. A node keeps a local cache of images and will reuse a tag it already has when the pull policy allows it. The advisory says the checkpoint import process did not check the image references inside a checkpoint's configuration, so a crafted checkpoint could pull an attacker's image and assign it a chosen local tag. Later pods that asked for that tag would run the attacker's image under their own identity.
Two classes apply, CWE-345 and CWE-829. The defence in depth is the same one supply chain teams already use: pin by digest, restrict registries, and limit who can start workloads.
Safeguard has a free in-browser dependency scan at gold.safeguard.sh/scan that matches the packages in a manifest against known CVEs. The Gold directory also lists container related CVEs, and container image scanning can check what is inside images you run.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Does this affect clusters where nobody uses checkpointing?
The advisory describes the CRI checkpoint import path. Upgrade anyway, since the fix is in a supported patch release for each line.
Sources
Last reviewed: 19 October 2026.
