CVE-2026-50195

What it actually does

The vulnerability is in containerd's Kubernetes CRI checkpoint import handling. A user who can create pods can supply a crafted checkpoint image whose configuration contains unvalidated image references. During import, vulnerable containerd versions can pull an attacker-controlled image and store it in the node-local image cache under an arbitrary tag chosen by the attacker. Later, any pod scheduled to the same node that references that tag with imagePullPolicy IfNotPresent or Never may run the cached malicious image instead of the intended legitimate image. The attacker’s code then executes with the identity, service account, mounted secrets, network access, and runtime context of the victim pod.

Why it matters to the business

This can turn limited pod-creation access into compromise of other workloads on the same Kubernetes node. The main operational risk is silent workload substitution: applications may appear to start normally while actually running attacker-controlled code, potentially exposing secrets, service credentials, internal APIs, and application data. The issue is not listed in CISA KEV and has a low EPSS score at the time provided, but it affects a core Kubernetes runtime component and can undermine trust in node-local container images, so shared clusters and multi-tenant environments should treat remediation as important.

How an attack unfolds

An attacker first needs authenticated access that allows pod creation or checkpoint import behavior that reaches the containerd CRI checkpoint import path. The attacker creates or obtains a checkpoint image with malicious configuration metadata that references an attacker-controlled image while assigning it a tag that matches a legitimate image expected to be used on the node. When the crafted checkpoint is imported on a vulnerable node, containerd does not properly validate the referenced image and populates the node's local image cache with the attacker's image under the chosen tag. The attacker then waits for, induces, or schedules a victim workload on that same node that uses the poisoned tag with IfNotPresent or Never pull policy. Because the runtime believes the image is already present locally, the victim pod starts with the malicious image. The malicious container code runs under the victim pod's permissions and can read mounted secrets, use the victim service account token, access allowed network destinations, and tamper with application behavior.

How to fix it

Upgrade containerd to a fixed release: 2.3.2 or later, 2.2.5 or later, or 2.1.9 or later, depending on the deployed branch. For managed Kubernetes services, apply the provider's node image/runtime updates and recycle affected nodes. After upgrading, treat node-local image caches on previously vulnerable nodes as untrusted: drain nodes, remove suspect cached images, prune unused containerd content where operationally safe, or rebuild/reimage nodes for high-assurance environments. If checkpoint import/restore functionality is not required, disable or restrict it. Reduce exploitability by limiting Kubernetes RBAC permissions for pod creation, preventing untrusted users from scheduling to shared nodes, enforcing admission controls for trusted registries and immutable image digests, and avoiding imagePullPolicy Never or IfNotPresent for mutable tags in sensitive workloads. Prefer digest-pinned images and admission policies that reject ambiguous or mutable tags such as latest.

How to confirm the fix worked

Confirm the runtime version on every Kubernetes node reports a fixed containerd version: 2.3.2+, 2.2.5+, or 2.1.9+. Validate through node package inventory, containerd --version, crictl info, or managed-service node image metadata. Review admission policy and workload manifests to identify pods using imagePullPolicy IfNotPresent or Never with mutable tags. On remediated nodes, verify checkpoint import behavior no longer accepts checkpoint image configurations that cause unvalidated image-reference retagging. Inspect node image caches with crictl images or ctr images ls for unexpected registries, duplicate tags with unexpected image IDs, or tags that do not match approved registry provenance. For high-value workloads, redeploy pods after cache cleanup or node rebuild to ensure they are running images resolved from trusted sources.

Typical attack path

1. Gain Kubernetes credentials or permissions that allow pod creation and access to checkpoint import/restore functionality on a vulnerable node.
2. Build a malicious container image and publish it to a registry controlled by the attacker or otherwise reachable by the node.
3. Craft a checkpoint image whose configuration causes vulnerable containerd to pull the malicious image and cache it locally under a tag that mimics a legitimate workload image.
4. Create a pod or trigger checkpoint import so the vulnerable node processes the crafted checkpoint image.
5. Poison the node-local image cache with the attacker-controlled image under the targeted tag.
6. Wait for or cause another pod on the same node to start using the targeted image tag with imagePullPolicy IfNotPresent or Never.
7. Execute attacker code under the victim pod's identity and use its secrets, service account, and network permissions for follow-on activity.

How to detect it

To determine whether exploitation already occurred, correlate Kubernetes audit logs, kubelet logs, containerd logs, image inventory, and registry access logs. Look for pod creation by low-privileged or unexpected users followed by checkpoint import or restore activity on the same node, then later victim pods starting with IfNotPresent or Never using an image tag that was already present locally. In containerd and kubelet logs, investigate checkpoint-related import messages, unexpected image pulls, or image tagging events where the source registry is unapproved but the final tag resembles a legitimate internal image. On nodes, compare crictl images or ctr images ls output against approved deployment manifests and registry digests; a strong signal is the same tag resolving locally to an image ID or digest that does not match the trusted registry digest. Review Kubernetes events for pods started without a fresh pull despite using tags that should have come from trusted registries. Also examine affected pods for signs of post-compromise activity: unexpected processes, modified entrypoints, unusual outbound network connections, access to mounted secrets, service account token use outside normal patterns, and calls to Kubernetes APIs from workloads that do not normally do so.

• checkpoint
• ImportCheckpoint
• checkpoint import
• checkpoint image
• imagePullPolicy: IfNotPresent
• imagePullPolicy: Never
• IfNotPresent
• Never
• crictl images
• ctr images ls
• unexpected local image tag
• unapproved registry
• image already present on machine
• Container image already present on machine
• Pulled image
• Pulling image
• Created container
• Started container

What your security team should do

• Prioritize upgrading all Kubernetes nodes running vulnerable containerd versions to 2.3.2+, 2.2.5+, or 2.1.9+ according to branch.
• Inventory clusters for workloads using imagePullPolicy IfNotPresent or Never, especially with mutable tags, and move critical workloads to digest-pinned images or imagePullPolicy Always where appropriate.
• Restrict pod creation, checkpoint, restore, and node-targeted scheduling permissions to trusted principals only.
• Use admission control to block untrusted registries, mutable image tags for sensitive namespaces, and checkpoint-related functionality where not explicitly required.
• Drain and rebuild or clean the image cache on nodes that were exposed before patching, especially in multi-tenant clusters.
• Hunt for unexpected local image tags, duplicate legitimate-looking tags with unknown image IDs, and images pulled from unapproved registries around the time checkpoint functionality was used.
• Increase monitoring of service account token use, secret access, and unusual outbound connections from pods that may have run from node-local cached images.