CVE-2026-47262

What it actually does

A malicious container image can trigger excessive memory consumption in vulnerable containerd versions when a container is created from that image. The memory exhaustion can cause the operating system OOM killer to terminate the containerd process, making the container runtime API unavailable. This can interrupt image pulls, container starts/stops, pod lifecycle operations, Docker Engine operations, and Kubernetes node/control-plane interactions that depend on containerd. The flaw requires the attacker to have some ability to cause a vulnerable host to create a container from the crafted image, such as pushing or referencing an image that an orchestrator, CI/CD job, or user later runs.

Why it matters to the business

Successful exploitation can disrupt container workloads by making the container runtime unavailable on affected hosts. In Kubernetes or Docker environments, this may prevent new containers from starting, interfere with workload recovery, and degrade availability of applications hosted on affected nodes. Because containerd is widely used as a default or common runtime across Kubernetes distributions and container platforms, the operational blast radius can be significant even though the issue is limited to availability impact. The CVE is not listed in CISA KEV, is not known to be used in ransomware campaigns, and currently has low EPSS, but it should still be prioritized for container platforms where untrusted or third-party images can be scheduled.

How an attack unfolds

An attacker first obtains the ability to influence what image is created on a vulnerable containerd host, such as through a registry, deployment manifest, CI job, build pipeline, or workload submission path. The attacker supplies a specially crafted image that exercises the vulnerable containerd behavior during container creation. When the host attempts to create a container from that image, containerd consumes excessive memory. The host kernel may invoke the OOM killer and terminate the containerd process. Once containerd exits, runtime API calls fail until the service is restarted, which can disrupt Docker Engine, kubelet, Kubernetes workload scheduling, pod management, and other clients that rely on the runtime.

How to fix it

Upgrade containerd to a fixed version for the deployed release line: 1.7.33 or later, 2.0.10 or later, 2.1.9 or later, 2.2.5 or later, or 2.3.2 or later. Where containerd is bundled with Docker Engine, Kubernetes distributions, managed node images, appliance software, or OS packages, apply the vendor-provided update that includes one of the fixed containerd versions. Restart containerd after patching and ensure dependent services such as kubelet or Docker Engine reconnect cleanly. As temporary mitigations, restrict who can submit workloads or image references, enforce image allowlisting or admission controls, block untrusted registries, require image signing or provenance verification, and monitor/limit memory pressure on container runtime hosts. Remove or quarantine any suspected crafted images from registries, local image caches, and workload definitions.

How to confirm the fix worked

Confirm the installed containerd version with commands such as `containerd --version`, package manager queries, node image inventory, or runtime endpoint inspection, and verify it is at least 1.7.33, 2.0.10, 2.1.9, 2.2.5, or 2.3.2 depending on the release line. Validate that the containerd service remains healthy after restart and that Docker Engine, kubelet, or other runtime clients can successfully create and manage containers. In Kubernetes environments, verify node readiness, kubelet runtime connectivity, and absence of recurring container runtime errors. Confirm exposure reduction by checking that image admission policies, registry restrictions, or signature requirements prevent untrusted images from being scheduled. Review logs for prior containerd OOM kills and correlate them with recent image pulls, container creation attempts, pod creations, CI jobs, or workload updates.

Typical attack path

1. Identify an environment that uses a vulnerable containerd release prior to 1.7.33, 2.0.10, 2.1.9, 2.2.5, or 2.3.2.
2. Gain the ability to cause the environment to create a container from an attacker-controlled or crafted image.
3. Publish, upload, or reference the malicious image through an allowed registry, deployment, CI/CD, or orchestration workflow.
4. Trigger container creation on a vulnerable host.
5. The vulnerable containerd process consumes excessive memory while handling the crafted image.
6. The operating system OOM killer terminates containerd, making the runtime API unavailable.
7. Container operations fail until containerd is restarted and the malicious image or workload is removed.

How to detect it

To determine whether exploitation may have already occurred, review host system logs, kernel logs, journald, containerd logs, Docker Engine logs, kubelet logs, Kubernetes events, CI/CD job logs, and registry audit logs. Focus on cases where containerd was terminated by the kernel OOM killer, restarted unexpectedly, or became unavailable immediately after a container creation, image pull, pod start, deployment rollout, or CI job using a specific image. On Linux systems, inspect `journalctl -u containerd`, `journalctl -k`, `/var/log/syslog`, `/var/log/messages`, `dmesg`, kubelet logs, and Docker daemon logs for OOM and runtime connection errors. In Kubernetes, correlate node `NotReady` transitions, pod sandbox creation failures, kubelet runtime connection failures, and containerd restarts with recently created pods and their image digests. Registry and admission logs can help identify whether an unusual or newly introduced image was pulled shortly before the crash. Because the observable artifacts are denial-of-service symptoms rather than unique malware markers, treat repeated containerd OOM kills during container creation from the same image digest as highly suspicious.

• Out of memory: Killed process
• Killed process containerd
• oom-kill:constraint=
• invoked oom-killer
• containerd.service: Main process exited
• containerd.service: Failed with result 'oom-kill'
• containerd.service: Failed with result 'signal'
• containerd.service: A process of this unit has been killed by the OOM killer
• container runtime is down
• failed to connect to containerd
• rpc error: code = Unavailable desc = connection error
• transport: Error while dialing dial unix /run/containerd/containerd.sock
• dial unix /run/containerd/containerd.sock: connect: connection refused
• failed to create containerd task
• failed to create shim task
• RunPodSandbox from runtime service failed
• CreateContainerError
• /run/containerd/containerd.sock
• /var/lib/containerd
• containerd

What your security team should do

• Inventory all systems, node images, Kubernetes distributions, container platforms, and appliances that include containerd, including indirect dependencies through Docker Engine or orchestration products.
• Prioritize upgrades on clusters, CI/CD workers, build hosts, multi-tenant platforms, and any environment where users can run third-party or untrusted images.
• Upgrade to containerd 1.7.33, 2.0.10, 2.1.9, 2.2.5, 2.3.2, or later according to the deployed release branch.
• Apply admission controls or registry allowlists to prevent untrusted images from being scheduled while patching is underway.
• Search historical system, kernel, containerd, kubelet, Docker, and orchestrator logs for OOM kills or runtime API failures involving containerd.
• Correlate any containerd OOM event with the exact image digest, registry source, workload, job, or deployment that triggered container creation.
• Remove or quarantine suspicious images and block their digests in registries, admission controllers, and CI/CD pipelines.
• Add monitoring for containerd memory growth, service exits, OOM killer events, and repeated runtime reconnect failures.