containerd CVE-2026-50195

The attacker must hold Kubernetes RBAC permissions sufficient to create pods in at least one namespace on the target cluster - specifically the ability to invoke the CRI checkpoint import path (e.g., via the kubelet checkpoint API or equivalent). The node must have containerd's checkpoint/restore feature accessible; environments that do not use or expose checkpoint functionality are not exposed to the poisoning step. Code execution on victim pods requires that those pods are (a) scheduled to the same node where poisoning occurred, and (b) configured with an IfNotPresent or Never image pull policy for the affected tag - pods using Always pull policy will fetch the real image from the upstream registry and are not affected. The attack does not require cluster-admin or node-level OS access to initiate, but the impact of successful exploitation is bounded by the victim pod's own Kubernetes identity and mounted credentials.

No CVSS vector or EPSS score is present in the provided data, so quantitative risk metrics cannot be cited - severity is vendor-stated as Critical via GHSA-cvxm-645q-p574. The attack prerequisite of pod-creation RBAC permission is a meaningful but not uncommon privilege in shared or multi-tenant Kubernetes clusters, making this a realistic insider or compromised-account threat vector. The attack is two-stage: poisoning requires the attacker to import a crafted checkpoint, while code execution requires a victim pod to start on the same node with an IfNotPresent or Never pull policy using the poisoned tag - this sequential dependency introduces operational complexity and limits opportunistic mass exploitation. The no-public-exploit and no-KEV status further modulates urgency. However, in environments where untrusted tenants hold pod-creation rights and checkpoint/restore is in use, the impact is severe: arbitrary code execution under a victim workload's identity, with access to its secrets, service account tokens, and downstream API access. This is a genuine priority for multi-tenant Kubernetes operators, but lower urgency for single-tenant or tightly RBAC-controlled environments.

An attacker with Kubernetes pod-creation RBAC permissions on a target namespace builds a malicious OCI checkpoint image that embeds forged image reference strings pointing to attacker-controlled registry content. They submit a pod spec that triggers containerd's CRI checkpoint import path, causing containerd to fetch the malicious image and register it locally under a tag matching a legitimate image expected by other workloads on the same node. When a subsequent victim pod is scheduled to that node and its image resolver finds the poisoned tag via IfNotPresent or Never pull policy, it launches the attacker's payload under the victim pod's service account identity - granting access to its mounted secrets, tokens, and any downstream APIs the victim was authorized to reach. No public proof-of-concept code has been identified at time of analysis.