CVE-2026-53489

What it actually does

containerd CRI versions before 2.3.2, 2.2.5, and 2.1.9 improperly restore the container.log file from a checkpoint image without validating whether the restored path is a symlink. A crafted checkpoint can cause the CRI log path to point at an arbitrary host file. When logs are later requested through the Kubernetes/container runtime log path, such as via kubectl logs, the runtime may read and return the targeted host file instead of normal container output. The primary impact is host file disclosure from the node running the affected container runtime; integrity and availability impact are not the main issue described.

Why it matters to the business

An attacker who can introduce or restore a malicious container checkpoint may be able to read sensitive files from Kubernetes worker nodes, potentially exposing secrets, credentials, configuration files, tokens, or other host data. In environments where containerd is widely deployed as the Kubernetes runtime, this can create a broad risk of credential theft and follow-on compromise even though the vulnerability is not currently listed in CISA KEV and has low EPSS at the time provided.

How an attack unfolds

An attacker first obtains a way to provide or trigger restoration of a crafted container checkpoint image on a node using an affected containerd CRI plugin. The checkpoint is constructed so that the expected container.log entry is a symlink to a sensitive host path, such as a credential, token, configuration, or key file. During checkpoint restoration, vulnerable containerd accepts the symlinked path without proper validation. The attacker then requests logs for the restored container through the normal Kubernetes or CRI log retrieval path. Instead of returning only container stdout/stderr logs, the runtime follows the unsafe reference and returns the contents of the targeted host file. The attacker can use any exposed secrets to escalate access, move laterally, or compromise workloads and infrastructure connected to the node.

How to fix it

Upgrade containerd to a fixed release: 2.3.2 or later for the 2.3.x branch, 2.2.5 or later for the 2.2.x branch, or 2.1.9 or later for the 2.1.x branch. If containerd is supplied by an operating system, Kubernetes distribution, managed node image, appliance, or vendor package, apply the vendor security update that includes the fixed containerd build. Restart containerd and, where required, kubelet or affected nodes so the patched runtime is active. As interim mitigation, restrict checkpoint restore functionality to highly trusted administrators, disable or block untrusted checkpoint image import/restore workflows where feasible, and enforce RBAC so ordinary workload users cannot trigger node-level restore operations or retrieve logs from containers they should not access. Treat any exposed host credentials as potentially compromised if exploitation is suspected.

How to confirm the fix worked

Confirm the active containerd version on each node using containerd --version, ctr version, crictl info, node image metadata, or distribution package inventory, and verify it is at least 2.3.2, 2.2.5, or 2.1.9 depending on branch. Confirm that all nodes have been restarted or that the runtime process has reloaded the updated binary. Review Kubernetes node runtime versions and package manager records to ensure no older containerd binaries remain in use. Where safe in a test environment, attempt to restore a checkpoint containing a symlinked container.log pointing to a benign host test file and verify that log retrieval is rejected or does not disclose the file. Also validate that RBAC and operational controls prevent untrusted users from restoring checkpoints or reading logs outside their authorization boundary.

Typical attack path

1. Identify a Kubernetes or containerd environment running containerd CRI before 2.3.2, 2.2.5, or 2.1.9.
2. Gain the ability to submit, import, or trigger restoration of a container checkpoint image on an affected node.
3. Create a checkpoint image where container.log is a symlink to a sensitive host file path.
4. Restore the crafted checkpoint through the affected CRI/containerd workflow.
5. Request logs from the restored container using kubectl logs, crictl logs, or an equivalent CRI log retrieval mechanism.
6. Collect disclosed host file contents and search them for credentials, tokens, configuration secrets, or other sensitive data.
7. Use any recovered secrets for privilege escalation, lateral movement, or further access to workloads and cluster resources.

How to detect it

Look for evidence that container checkpoint restore functionality was used in combination with suspicious log retrieval. Useful sources include Kubernetes API audit logs, kubelet logs, containerd logs, CRI logs, shell history on nodes, endpoint telemetry, and file-system artifacts in containerd checkpoint/import locations. In Kubernetes audit logs, review create/get requests involving pod logs, especially kubectl logs activity shortly after checkpoint restore operations or involving unusual users, service accounts, namespaces, or restored containers. In node logs, search for checkpoint restore, image import, task/container creation, and log open/read events around the same timestamps. On disk, inspect checkpoint archives or restored checkpoint directories for a container.log entry that is a symlink, especially one pointing to absolute host paths or path traversal targets. File access telemetry is valuable: suspicious reads of host files by containerd, kubelet, or CRI-related processes when servicing log requests may indicate exploitation. Because this vulnerability does not necessarily produce a unique network signature, correlate restore activity, log retrieval, symlinked container.log artifacts, and subsequent credential use from node or cluster secrets.

• container.log -> /
• container.log -> ../
• container.log -> /etc/passwd
• container.log -> /etc/shadow
• container.log -> /var/lib/kubelet/
• container.log -> /var/lib/kubelet/pki/
• container.log -> /var/lib/kubelet/config.yaml
• container.log -> /var/lib/kubelet/pods/
• container.log -> /etc/kubernetes/
• container.log -> /etc/kubernetes/kubelet.conf
• container.log -> /var/lib/containerd/
• kubectl logs
• crictl logs
• /var/log/pods/
• /var/log/containers/
• checkpoint
• restore
• containerd
• io.containerd.grpc.v1.cri

What your security team should do

• Inventory all Kubernetes nodes, container hosts, node images, and container platform appliances that use containerd CRI, prioritizing internet-facing, multi-tenant, shared, or high-sensitivity clusters.
• Patch containerd to 2.3.2, 2.2.5, 2.1.9, or a later vendor-fixed package, and recycle affected nodes where necessary to ensure the fixed runtime is active.
• Temporarily restrict checkpoint restore/import workflows to trusted platform administrators until all nodes are confirmed patched.
• Review Kubernetes RBAC and admission controls to ensure users cannot restore checkpoints or read pod logs unless explicitly required.
• Search for evidence of unusual checkpoint restore activity and log retrieval from restored containers, especially requests followed by exposure of data resembling host files, tokens, keys, or system configuration.
• If exploitation is suspected, rotate node-level credentials, Kubernetes service account tokens, registry credentials, cloud credentials, and other secrets that may have been readable from affected host paths.
• Add this vulnerability to base image, node image, and container runtime compliance checks so older containerd versions are blocked from re-entering production.