containerd CVE-2026-53489

Exploitation requires that the containerd CRI plugin performs a checkpoint restore of an attacker-controlled or attacker-influenced checkpoint image containing a container.log entry that is a symlink to a host file; the payload is then read when someone invokes kubectl logs against the restored container. Limiting factors: the environment must actually use CRI checkpoint/restore (a non-default, opt-in feature), the attacker must be able to get a malicious checkpoint image restored (implying some workload-scheduling or image-supply capability despite the official PR:N rating), the attack vector is local to the node (AV:L, not remote/network), and impact is confined to file read/disclosure (VC:H, SC:H) with no integrity or availability effect. In clusters that never restore untrusted checkpoints, the condition is not met and risk is effectively neutralized.

The CVSS 4.0 base score is 8.2 (High) with vector AV:L/AC:L/AT:N/PR:N/UI:N and VC:H plus SC:H, signalling high confidentiality impact on both the vulnerable and a subsequent system (the host) with local access and no user interaction. The most important limiting signal is the prerequisite that the victim environment restores a checkpoint image the attacker controls - the vendor workaround ('only use trusted images and checkpoints') confirms this is fundamentally a malicious-input problem, so exploitation is realistic mainly where untrusted checkpoint images are accepted, not against every default deployment. No EPSS score was provided in the input, containerd is not listed in CISA KEV, and no POC was supplied, so this is a real-but-conditional priority rather than a mass-exploited internet-facing bug: patch promptly on multi-tenant or checkpoint-enabled clusters, lower urgency where checkpoint/restore is unused. Note a tension to flag: the official vector marks PR:N, yet actually introducing and restoring a crafted checkpoint typically requires some level of cluster/workload access, so the practical privilege bar is higher than PR:N implies - verify against your admission and checkpoint-provisioning controls.

An attacker able to supply or influence a container checkpoint image embeds a container.log entry that is actually a symlink to a sensitive host file such as /etc/shadow or a service-account token. After the malicious checkpoint is restored on a node, the attacker (or an unwitting operator) runs kubectl logs against the resulting pod, and containerd dereferences the symlink and returns the host file's contents. No public exploit code was provided in the input, and the local attack vector with low complexity means exploitation is straightforward once a crafted checkpoint reaches the runtime.