CVE-2026-47262: containerd Denial of Service Vulnerability

CVE-2026-47262 Overview

CVE-2026-47262 is a denial of service vulnerability in containerd, an open-source container runtime widely used by Docker Engine and Kubernetes. A maliciously crafted container image triggers memory exhaustion during container creation, causing the Linux Out Of Memory (OOM) killer to terminate the containerd process. The resulting outage renders the container runtime API unavailable and disrupts higher-level clients such as the Docker Engine and Kubernetes control-plane components. The issue is classified under [CWE-400] Uncontrolled Resource Consumption and is fixed in containerd versions 1.7.33, 2.0.10, 2.1.9, 2.2.5, and 2.3.2.

Critical Impact
A single malicious image can crash containerd, breaking Kubernetes node runtime availability and disrupting all workloads scheduled on the affected node.

Affected Products

containerd versions prior to 1.7.33 in the 1.7.x branch
containerd versions prior to 2.0.10, 2.1.9, and 2.2.5 in the 2.x branches
containerd versions prior to 2.3.2 in the 2.3.x branch

Discovery Timeline

2026-07-01 - CVE-2026-47262 published to NVD
2026-07-02 - Last updated in NVD database

Technical Details for CVE-2026-47262

Vulnerability Analysis

The vulnerability resides in containerd's image handling logic during container creation. When containerd processes a maliciously crafted image, it consumes memory without effective bounds, exhausting the host's available memory. The Linux kernel's OOM killer then terminates the containerd process to reclaim resources. Because containerd exposes the runtime API used by Docker Engine and Kubernetes kubelet, its termination breaks container lifecycle management on the affected host. Workloads on Kubernetes nodes lose their runtime, and control-plane operations dependent on the CRI socket fail.

Root Cause

The root cause is uncontrolled resource consumption [CWE-400] in the image processing path. containerd does not enforce sufficient limits on memory allocations driven by attacker-controlled image metadata or content. An adversary crafts an image whose structure forces containerd to allocate excessive memory during unpacking or container creation, exceeding host capacity.

Attack Vector

The attack requires an authenticated user with permission to instantiate containers from an image the attacker controls. In multi-tenant Kubernetes clusters, a namespace user able to specify arbitrary image references can trigger the condition on any node scheduled to pull and run the image. Container registries that host user-supplied images can serve as delivery vectors.

No verified public exploit code is available. The vulnerability mechanism is documented in the containerd GitHub Security Advisory GHSA-jpcc-p29g-p8mq.

Detection Methods for CVE-2026-47262

Indicators of Compromise

Kernel oom-killer log entries targeting the containerd process in /var/log/messages, journalctl, or dmesg output.
Sudden termination and restart of the containerd.service systemd unit correlated with image pull or container create operations.
Kubernetes node transitioning to NotReady state with kubelet reporting CRI runtime connection errors to /run/containerd/containerd.sock.

Detection Strategies

Monitor host memory utilization for rapid spikes during ctr, crictl, or kubelet-driven container creation events.
Correlate containerd process restarts with recent image pulls from untrusted or user-controlled registries.
Alert on repeated OOM kill events referencing container runtime binaries across the fleet, which may indicate targeted DoS attempts.

Monitoring Recommendations

Enable Prometheus scraping of containerd metrics and node-exporter memory metrics, alerting on containerd restart counters.
Log and audit all image references pulled by kubelet, flagging images from registries outside the approved allowlist.
Track Kubernetes events for FailedCreatePodSandBox and node NotReady transitions tied to CRI errors.

How to Mitigate CVE-2026-47262

Immediate Actions Required

Upgrade containerd to 1.7.33, 2.0.10, 2.1.9, 2.2.5, or 2.3.2 depending on your deployed branch.
Restrict container image sources to trusted registries using admission controllers such as Kyverno, OPA Gatekeeper, or Kubernetes ImagePolicyWebhook.
Audit RBAC policies to limit which principals can create pods or specify arbitrary image references in multi-tenant clusters.

Patch Information

The containerd maintainers released fixes in versions 1.7.33, 2.0.10, 2.1.9, 2.2.5, and 2.3.2. Details are published in the containerd GitHub Security Advisory GHSA-jpcc-p29g-p8mq. Operators using distribution-packaged containerd (Amazon Linux, Ubuntu, RHEL, SUSE) should apply vendor updates that incorporate these upstream fixes.

Workarounds

Enforce image signing and verification with Sigstore Cosign or Notation to block unsigned or untrusted images before they reach the runtime.
Apply cgroup memory limits to the containerd.service unit to contain damage, while accepting that OOM kills of containerd itself remain possible.
Isolate untrusted workloads using sandboxed runtimes such as gVisor or Kata Containers on dedicated node pools until patches are deployed.

bash

# Verify containerd version and upgrade on a Linux host
containerd --version

# Debian/Ubuntu example
sudo apt-get update && sudo apt-get install --only-upgrade containerd.io

# RHEL/CentOS/Amazon Linux example
sudo dnf upgrade containerd.io

# Restart the service and confirm the fixed version
sudo systemctl restart containerd
containerd --version