Summary
A bug in containerd's CRI plugin causes container.log to be restored from a checkpoint image without validating whether the path is a symlink. An attacker who can supply a crafted checkpoint image can use this to make containerd follow a symlink that points to an arbitrary file on the host, which is then exposed via kubectl logs.
Impact
An attacker with permissions to create pods and supply a crafted checkpoint image can read arbitrary files on the node host filesystem by causing container.log to be a symlink to any readable path. Because the file content is surfaced through kubectl logs, no direct node access is required after the checkpoint is restored. Sensitive files such as service account tokens, certificates, and configuration files in the host's filesystem could be disclosed to any user who can run kubectl logs against the affected pod.
Detection
Nodes running containerd v2.1.0–v2.1.8, v2.2.0–v2.2.4, or v2.3.0–v2.3.1 are in the affected version range. Verify the running version:
containerd --version
Inspect checkpoint archives before use for symlinked container.log entries. Audit kubectl logs access and checkpoint restore operations in the cluster's audit log to detect potential exploitation attempts.
Mitigation
Upgrade to one of the patched containerd releases:
- containerd v2.3.x: upgrade to v2.3.2 or later
- containerd v2.2.x: upgrade to v2.2.5 or later
- containerd v2.1.x: upgrade to v2.1.9 or later
As a workaround, ensure that only trusted images and checkpoints are used. Restricting which users can perform checkpoint/restore operations and limiting pod creation to trusted users reduces the risk on clusters that cannot upgrade immediately.
Related Security Guidance
References
- GHSA-rgh6-rfwx-v388 — GitHub Security Advisory
- NVD CVE-2026-53489 — National Vulnerability Database