CVE-2026-47262: containerd Memory Exhaustion Denial of Service Vulnerability

Technical summary

containerd prior to specified patched versions does not properly validate or constrain resource consumption during image processing when creating a container from a maliciously crafted image. The vulnerability manifests as uncontrolled memory allocation (CWE-400: Uncontrolled Resource Consumption), which exhausts the heap and triggers an out-of-memory killer event at the kernel level. This results in immediate termination of the containerd daemon, rendering the container runtime API unavailable until manual restart. The condition can be triggered by any user with the ability to create containers from untrusted images, whether locally or via a remote registry.

Business impact

Containerd downtime directly disrupts container operations. In Kubernetes environments, this can cascade into control-plane instability and workload evictions. In Docker-based deployments, all containers managed by that daemon become unavailable. Organizations relying on continuous container deployments will experience service interruptions, failed CI/CD pipelines, and potential SLA breaches. The attack requires no network privilege—only the ability to create a container from a crafted image—making it a practical denial-of-service vector in multi-tenant or untrusted-image scenarios.

Affected systems

This vulnerability affects all versions of containerd prior to version 1.7.33 (legacy), 2.0.10, 2.1.9, 2.2.5, and 2.3.2. Kubernetes clusters using containerd as their container runtime are directly exposed. Docker installations that use containerd as their underlying runtime (most modern Docker on Linux) are also affected. Any deployment accepting container images from untrusted sources or registry feeds is at risk. Organizations running older containerd branches or locked to specific minor versions should verify their exact release line against the patched versions.

Exploitability

Exploitation requires the ability to either push a malicious image to a registry that the target pulls from, or to have local container creation privileges. For internal Kubernetes clusters or Docker daemons accepting images only from trusted registries, the risk is lower but not eliminated if registry compromise is within the threat model. The attack is trivial once an attacker can introduce a crafted image—no special tooling, no authentication bypass, and no user interaction beyond standard container creation. Severity is marked MEDIUM due to the requirement for local or prior-image-supply access, but impact is HIGH given the service disruption caused.

Remediation

Patch containerd immediately to one of the fixed versions: 1.7.33, 2.0.10, 2.1.9, 2.2.5, or 2.3.2 depending on your deployment branch. Verify which branch you are running and upgrade to the earliest patched version in that line. For Kubernetes, this typically involves upgrading the containerd binary on all nodes and restarting the daemon. For Docker, upgrade Docker to a version that bundles the patched containerd. In the interim, restrict container image sources to trusted, scanned registries and implement image scanning policies that reject suspicious resource-declaration patterns.

Patch guidance

Identify your current containerd version using 'containerd --version'. Cross-reference against the affected versions (anything before 1.7.33, 2.0.10, 2.1.9, 2.2.5, or 2.3.2). Download the patched release from the Linux Foundation's containerd GitHub releases page. For Kubernetes, upgrade containerd on each node, then restart the kubelet. For Docker, update Docker Engine via your distribution's package manager or Docker's official repositories—verify that the bundled containerd version matches a patched release. Test container creation with sample images post-upgrade to confirm normal operation.

Detection guidance

Monitor containerd daemon restarts and OOM killer events in kernel logs (dmesg, systemd journal). Alert on repeated 'containerd' OOM kills within short time windows, which indicate potential exploitation attempts. Review image pull logs for unusual or unexpected images being created. Implement image scanning at the registry level to detect resource-bomb manifests (though signature detection is difficult for this class of flaw). Network segmentation to trusted registries and image pull policies reduce exposure. Correlate containerd daemon downtime with container creation events in audit logs to identify patterns.

Why prioritize this

Although marked MEDIUM severity due to access requirements, this vulnerability should be prioritized as HIGH within any environment that creates containers from untrusted or external image sources. Kubernetes clusters and Docker-in-Docker setups are particularly sensitive. The complete denial of service to the runtime makes it a business-continuity risk, and patching is straightforward with minimal operational friction. Organizations should patch before accepting any new images from public registries or user-supplied sources.

Risk score, explained

CVSS 3.1 score of 5.5 (MEDIUM) reflects local or pre-supplied-image access requirement (AV:L), no special attack complexity (AC:L), no privilege escalation needed (PR:N), but high availability impact (A:H) with no confidentiality or integrity loss. The score appropriately weights the accessibility constraint against the severe service disruption. However, in multi-tenant or CI/CD environments where image sources are less controllable, real-world risk may exceed the base score.

Frequently asked questions