Database/Container, Kubernetes & orchestration

containerd: crafted OCI image index exhausts node CPU and memory during image pull

CVSS 6.9CVE-2026-53493Container, Kubernetes & orchestrationcurated

Impact

A crafted OCI index graph makes containerd burn very high CPU and memory while pulling the image, before any container starts. On a GPU node this shows up as pods stuck in ContainerCreating and, at larger index sizes, runtime or node instability - so a single tenant who controls which image reference gets pulled can degrade or take out a node that other tenants' workloads are scheduled on. The cost is paid by the node-level runtime, not the pod, so pod-level CPU and memory limits do not contain it. Impact is availability only; there is no disclosure or code execution in this issue.

Who can reach it

Anyone who can cause the node to pull an image they control - any tenant permitted to specify an image reference in a pod spec, or a compromised or attacker-influenced registry serving an existing reference. No authentication to containerd itself is needed.

What to do

Upgrade containerd to 1.7.36, 2.0.13, 2.2.9, 2.3.6, or 2.4.1 depending on your branch. containerd is restarted as part of the package upgrade; on recent versions running containers survive the restart, but plan it per node and cordon first if your workloads are sensitive to a brief runtime outage. Interim mitigation: restrict pulls to registries you control via admission policy.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-53493 https://github.com/containerd/containerd/security/advisories/GHSA-pg57-6jwg-q645

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.