CVE-2026-53489: containerd Path Traversal Vulnerability

CVE-2026-53489 Overview

CVE-2026-53489 is a symlink-following vulnerability in containerd, an open-source container runtime widely used by Kubernetes and Docker. The Container Runtime Interface (CRI) plugin restores container.log from a checkpoint image without validating whether the target path is a symbolic link. An attacker who can supply a crafted checkpoint image can read arbitrary files on the host through kubectl logs. The flaw is categorized as an Unix Symbolic Link (Symlink) Following weakness [CWE-61]. Fixed releases are containerd 2.3.2, 2.2.5, and 2.1.9.

Critical Impact
A local attacker with checkpoint image control can exfiltrate arbitrary host files through kubectl logs, bypassing container isolation boundaries.

Affected Products

containerd versions prior to 2.3.2
containerd versions prior to 2.2.5 in the 2.2.x branch
containerd versions prior to 2.1.9 in the 2.1.x branch

Discovery Timeline

2026-07-01 - CVE-2026-53489 published to NVD
2026-07-02 - Last updated in NVD database

Technical Details for CVE-2026-53489

Vulnerability Analysis

The vulnerability lives in the containerd CRI plugin's checkpoint restore logic. When a container is restored from a checkpoint image, the plugin recreates container.log on the host filesystem using the path recorded in the checkpoint archive. The plugin does not verify whether the destination path resolves through a symbolic link before opening or reading it.

An attacker who supplies a malicious checkpoint image can embed a symlink where container.log is expected. When the CRI plugin restores the container and a user issues kubectl logs, the kubelet reads through the symlink and returns the target file's contents. This exposes any file readable by the container runtime process, which typically runs as root.

Root Cause

The root cause is missing path validation during checkpoint restoration [CWE-61]. The CRI plugin trusts the archive-supplied log path and performs no O_NOFOLLOW check or realpath resolution against the container rootfs. Symlink resolution occurs in the host mount namespace, so links can point anywhere the containerd process can read.

Attack Vector

Exploitation requires local access to submit or import a crafted checkpoint image into the cluster. The attacker builds a checkpoint archive in which container.log is a symlink to a sensitive host file such as /etc/shadow, /root/.kube/config, or a mounted service account token. After the container is restored, invoking kubectl logs <pod> streams the target file back through the Kubernetes API. No authentication bypass or memory corruption is required; the flaw is a logic failure in symlink handling during restore. The advisory notes exploitation is limited to actors who can influence checkpoint images, which restricts blast radius but does not eliminate risk in multi-tenant clusters.

Detection Methods for CVE-2026-53489

Indicators of Compromise

Unexpected container.log files inside container rootfs directories that resolve to paths outside the container filesystem.
kubectl logs output containing content that does not match container stdout or stderr, such as configuration files or credentials.
Checkpoint restore events in containerd logs referencing images from untrusted registries or user-controlled sources.

Detection Strategies

Audit containerd CheckpointContainer and RestoreContainer API calls and correlate them with subsequent kubectl logs requests.
Inspect the target of container.log in the containerd state directory (typically /var/lib/containerd) and flag any entry that is a symbolic link.
Monitor for reads by the containerd or kubelet process against sensitive host paths such as /etc/shadow, /root/, or service account token mounts.

Monitoring Recommendations

Enable Kubernetes audit logging for pods/log subresource requests and alert on high-volume access to newly restored pods.
Deploy runtime file-integrity monitoring on the containerd state directory to catch symlink creation events.
Track containerd versions across nodes and alert when versions below 2.1.9, 2.2.5, or 2.3.2 are detected.

How to Mitigate CVE-2026-53489

Immediate Actions Required

Upgrade containerd to 2.3.2, 2.2.5, or 2.1.9 on every node in every cluster.
Restrict who can push, pull, or import checkpoint images. Treat checkpoint archives as untrusted input equivalent to arbitrary container images.
Disable the CRI checkpoint or restore feature on nodes that do not require it until patched.

Patch Information

The containerd maintainers released fixes in versions 2.3.2, 2.2.5, and 2.1.9. The patched code validates that container.log is a regular file within the expected container directory before restoration proceeds. Full details are available in the GitHub Security Advisory GHSA-rgh6-rfwx-v388.

Workarounds

Block the checkpoint and restore CRI RPCs at the admission controller layer if patching is delayed.
Enforce image provenance with signature verification such as Sigstore cosign to prevent unsigned checkpoint images from being restored.
Apply mandatory access control profiles such as AppArmor or SELinux to constrain containerd's read access to sensitive host paths.

bash

# Verify installed containerd version on each node
containerd --version

# Example upgrade path on a Debian-based node
sudo apt-get update && sudo apt-get install --only-upgrade containerd.io

# Confirm patched version (must be >= 2.1.9, 2.2.5, or 2.3.2)
containerd --version | awk '{print $3}'