CVE-2026-53493 in containerd
Summary
by MITRE • 09/25/2026
containerd is an open-source container runtime. Prior to versions 1.7.36, 2.0.13, 2.2.9, 2.3.6, and 2.4.1, a crafted OCI index graph can force very high CPU/memory usage during PullImage (before container start), causing long ContainerCreating stalls and, at larger sizes, node/runtime instability. Versions 1.7.36, 2.0.13, 2.2.9, 2.3.6, and 2.4.1 fix the issue.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/25/2026
The vulnerability identified in containerd, a widely adopted open-source container runtime used by Kubernetes and other orchestration platforms, represents a significant resource exhaustion risk during image pull operations. Prior to the release of versions 1.7.36, 2.0.13, 2.2.9, 2.3.6, and 2.4.1, the runtime exhibited a critical flaw in its handling of Open Container Initiative (OCI) index graphs. Specifically, when processing crafted or malformed OCI indexes during the PullImage phase, which occurs before container instantiation, the system failed to properly limit resource consumption based on image metadata complexity rather than just size. This architectural oversight allowed an attacker or misconfigured workflow to trigger excessive CPU and memory allocation by supplying a specially constructed manifest that forced the runtime into inefficient processing loops or recursive graph traversals with unbounded depth or breadth.
From a technical perspective, this flaw aligns closely with CWE-400, which describes Uncontrolled Resource Consumption, as well as CWE-755: Improper Handling of Unexpected Data Type. The OCI specification allows for complex manifest structures that can reference multiple layers and platforms. In vulnerable versions, containerd did not adequately sanitize or bound the processing logic when resolving these references during the pull operation. Consequently, a single maliciously crafted image index could cause the runtime to consume disproportionate amounts of system resources while attempting to resolve dependencies and validate signatures before ever starting a container process. This behavior is particularly dangerous because it occurs at the infrastructure layer, affecting not just individual containers but potentially destabilizing the entire node or cluster where the runtime operates.
The operational impact of this vulnerability extends beyond simple performance degradation. During normal operations, when an image pull triggers high CPU and memory usage due to such a crafted index, Kubernetes nodes experience prolonged states in ContainerCreating status for subsequent pods that depend on similar images or share resource quotas. This leads to significant scheduling delays and application latency. In more severe scenarios involving larger or more complex malicious indexes, the excessive load can cause node-level instability, leading to container runtime crashes, eviction of other critical workloads due to memory pressure, or even complete node unresponsiveness requiring a reboot. For environments relying on automated image scanning or CI/CD pipelines that pull images from potentially compromised registries, this vulnerability presents a direct path for denial-of-service attacks against the orchestration layer itself.
Mitigation strategies primarily involve upgrading containerd to one of the patched versions listed above: 1.7.36, 2.0.13, 2.2.9, 2.3.6, or 2.4.1. These releases include fixes that enforce stricter limits on resource consumption during image resolution and validate OCI index structures more rigorously to prevent unbounded processing loops. In addition to upgrading the runtime, organizations should implement strict image admission policies using tools like OPA Gatekeeper or Kyverno to reject images with overly complex manifest structures before they reach the node level. Furthermore, integrating vulnerability scanning solutions that check for known CVEs in container runtimes and enforcing least-privilege access controls for registry interactions can reduce the attack surface. Monitoring CPU and memory metrics during image pull events is also recommended to detect anomalous behavior indicative of such exploitation attempts.
This incident highlights the importance of securing not just application code but also the underlying runtime infrastructure that manages it. The ATT&CK framework categorizes this type of resource exhaustion under T1496: Resource Hijacking, where adversaries leverage compromised or malicious resources to consume system capacity for denial-of-service purposes. By addressing this vulnerability through timely patching and implementing defense-in-depth strategies such as image signing verification and runtime monitoring, organizations can maintain the stability and availability of their containerized environments against sophisticated resource-based attacks.