Database/Container, Kubernetes & orchestration

containerd: malicious image layer causes repeated directory traversal during unpack, stalling image pulls

CVSS 4.6CVE-2026-95838Container, Kubernetes & orchestrationcurated

Impact

A crafted image layer makes containerd's unpack handler walk the same directories over and over while processing opaque whiteouts, burning CPU on the node that pulls it. On a GPU node this is felt as delayed container startup and reduced image-pull concurrency, which also slows unrelated deployments scheduled to the same node - and GPU images are already large, so the pull path is a contended resource. No confidentiality or integrity impact is claimed; the advisory describes availability degradation only. Anyone who can get an image pulled onto a node, including through a tenant-supplied image reference, can trigger it.

Who can reach it

Anyone who can cause a node to pull or import an image - a tenant submitting a pod spec with their own image reference, or an operator importing an untrusted tarball. No authentication to containerd itself is needed; the attacker only needs their image to be pulled.

What to do

Upgrade containerd to 1.7.35, 2.0.12, 2.2.8, or 2.3.5 depending on your branch and restart the containerd daemon on each node. Restarting containerd does not require draining running containers in a normal Kubernetes setup, but pulls and container lifecycle operations pause briefly, so roll it node by node. Until patched, restrict which registries nodes may pull from.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-95838 https://github.com/containerd/containerd/security/advisories/GHSA-rp3h-jf77-q9p4 https://github.com/containerd/containerd/commit/e6ca378dcfa610d06589a3ac96aa992de866e4f0

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.