CVE-2026-53493: 
Packer vulnerability analysis and mitigation

CVE-2026-53493 is an image-pull denial-of-service vulnerability in containerd, an open-source container runtime, caused by unbounded traversal of crafted OCI image index descriptor graphs. A remote, unauthenticated attacker can supply a malicious OCI image index with deeply nested or heavily fanned-out descriptor graphs to trigger excessive CPU and memory consumption during the PullImage operation, before any container starts. Affected versions include containerd prior to 1.7.36, 2.0.x before 2.0.13, 2.1.x–2.2.x before 2.2.9, 2.3.x before 2.3.6, and 2.4.0. The vulnerability was published on September 25, 2026, and carries a CVSS v4.0 base score of 6.9 (Medium) (GitHub Advisory).

The root cause is uncontrolled resource consumption (CWE-400) combined with allocation without limits or throttling (CWE-770) and excessive iteration (CWE-834). During PullImage, containerd recursively traverses and processes child descriptors in an OCI image index without enforcing sufficient depth or breadth limits, and without adequately deduplicating identical descriptors. An attacker can craft an OCI index graph that is deeply nested or heavily fanned-out, causing the traversal to expand exponentially (analogous to CAPEC-197 Exponential Data Expansion or CAPEC-491 Quadratic Data Expansion), consuming unbounded CPU and memory on the host. The vulnerability is exploitable over the network with no privileges or user interaction required, and occurs entirely in the image pull phase prior to container execution (GitHub Advisory).

Successful exploitation causes prolonged ContainerCreating stalls and significant resource pressure on the host system, degrading or halting container scheduling. At larger crafted graph sizes, the resource exhaustion can destabilize the container runtime or the node itself, affecting all workloads running on that node. There is no confidentiality or integrity impact; the vulnerability is limited to availability, but node-level instability in a Kubernetes or similar orchestrated environment could cascade to broader service disruption (GitHub Advisory).

No public proof-of-concept exploit code or in-the-wild exploitation has been reported as of the publication date. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. The EPSS score is approximately 0.356%, indicating a low near-term exploitation probability (Feedly). The attack requires no authentication and no user interaction, making it theoretically straightforward to trigger against any containerd instance that pulls images from attacker-controlled or compromised registries.

1. Set up a malicious OCI registry: Host a container registry (e.g., using a tool like zot or a custom HTTP server) that serves a crafted OCI image index manifest.
2. Craft the malicious OCI index: Create an OCI image index JSON with a deeply nested or heavily fanned-out descriptor graph — for example, an index referencing thousands of child manifests, each referencing further child manifests, or circular/repeated references that exploit the lack of deduplication.
3. Reference the malicious image: Ensure the target containerd node is configured or tricked into pulling from the attacker-controlled registry (e.g., via a Kubernetes pod spec referencing the malicious image tag).
4. Trigger PullImage: Submit a container creation request referencing the malicious image. Containerd initiates PullImage, begins recursive traversal of the OCI index graph, and exhausts CPU and memory resources.
5. Observe impact: The node experiences prolonged ContainerCreating stalls; at sufficient graph size, the containerd runtime or node becomes unstable, denying service to all workloads (GitHub Advisory).

• Logs: Containerd or kubelet logs showing extended ContainerCreating states for pods referencing external or unfamiliar image references; repeated or stalled PullImage gRPC calls in containerd debug logs.
• Process/Resource: Abnormally high CPU and memory usage by the containerd process (containerd, containerd-shim) visible via top, htop, or node monitoring dashboards, without a corresponding increase in running containers.
• Network: Outbound connections from the node to unfamiliar or unexpected container registry endpoints during the stall period.
• Kubernetes Events: Kubernetes events showing Failed to pull image or indefinitely pending pods with ContainerCreating status referencing suspicious image sources (GitHub Advisory).

Users should upgrade containerd to one of the patched versions: 1.7.36, 2.0.13, 2.2.9, 2.3.6, or 2.4.1. There are no known configuration-based workarounds. As an interim measure, the containerd project advises pulling only trusted images from known, controlled registries to reduce exposure until the patch can be applied (GitHub Advisory).

The vulnerability was independently discovered and responsibly disclosed by Jakub Ciolek at ElevenLabs and @jlgore, credited in the official advisory. A brief technical blog post was published by Suriq covering the image-pull DoS mechanism (Suriq Blog), and the disclosure was noted on Mastodon/infosec.exchange (Suriq Mastodon). No major vendor statements beyond the containerd project's own advisory have been identified.