Can this be used to run code on the node?

The advisory describes resource exhaustion during image pull, before any container runs. It does not describe code execution.

Is it exploitable without cluster access?

Someone has to make a node pull the crafted image. That takes the ability to create a workload with an image reference of their choosing, or control of a registry or image your workloads already pull from.

This advisory is for containerd. CRI-O published a separate denial-of-service advisory for crafted OCI images, CVE-2026-17113, in August 2026.

CVE-2026-53493: containerd image pull denial of service from a crafted OCI index

What the vulnerability does

During PullImage, containerd walks the descriptor graph of an image index to find what to fetch. The advisory says that traversal had no adequate depth or breadth limit and did not deduplicate identical descriptors, so an index built to nest deeply or fan out widely makes containerd allocate CPU and memory without bound.

The effect is a stall: container creation hangs on the node and the host comes under resource pressure. It all happens during the pull, before any container from that image runs, so it is an availability problem, not code execution.

Affected and fixed versions

From the containerd advisory.

containerd/v2: 2.0.0 before 2.0.13, 2.1.0 before 2.2.9, 2.3.0 before 2.3.6, and 2.4.0.
containerd 1.x: 1.7.35 and earlier.
Fixed: 2.4.1, 2.3.6, 2.2.9, 2.0.13 and 1.7.36.
No workaround: the advisory's only advice before patching is to pull images from trusted registries only.

Check your exposure

Two questions decide how much this matters: which nodes run an affected containerd, and who can make those nodes pull an image reference of their choosing. The second is usually anyone who can create a pod, a Job or a Deployment with an arbitrary image.

ShellRuntime versions, then every image reference in use

kubectl get nodes -o custom-columns=\
NODE:.metadata.name,\
RUNTIME:.status.nodeInfo.containerRuntimeVersion

kubectl get pods -A -o jsonpath=\
'{range .items[*]}{range .spec.containers[*]}\
{.image}{"\n"}{end}{end}' | sort -u

Any registry in that list that you do not control is a place a crafted index could come from. An admission policy that only allows your own registries closes most of it.

What it looks like when it happens

Nothing from the image ever runs, so there is no suspicious process to find in the workload. The signs are on the node: pods stuck in ContainerCreating or Pending on one node while pulling, and the containerd process itself using far more CPU and memory than usual during a pull.

That makes it worth recording which image reference each stalled pod was pulling and who created the pod. The same pull on another node will stall it too.

Fixing it

Upgrade containerd to 2.4.1, 2.3.6, 2.2.9, 2.0.13 or 1.7.36. On managed Kubernetes that usually means a node image update from your provider. Until then, restrict image references to registries you control with an admission policy.

Frequently asked questions

Can this be used to run code on the node?: The advisory describes resource exhaustion during image pull, before any container runs. It does not describe code execution.
Is it exploitable without cluster access?: Someone has to make a node pull the crafted image. That takes the ability to create a workload with an image reference of their choosing, or control of a registry or image your workloads already pull from.
Is CRI-O affected?: This advisory is for containerd. CRI-O published a separate denial-of-service advisory for crafted OCI images, CVE-2026-17113, in August 2026.

Sources and references

GHSA-pg57-6jwg-q645: Image-pull DoS via crafted OCI index graph amplification
containerd, September 2026
OCI Image Index Specification
Open Container Initiative