Containerd
Monthly
Native code execution inside the shim zygote process is possible in runwasi's containerd-shim-wasmtime-v1 prior to 0.6.1 when a victim pulls and runs an attacker-crafted OCI image whose single Wasm layer is actually Wasmtime precompiled (serialized native-code) bytes. Because the shim trusts precompiled-format bytes from image layers as if they came from the trusted precompile-cache path, it deserializes them without normal WebAssembly validation, yielding the filesystem, environment, credentials, networking, and Linux syscall access of the workload container; the escape reaches the workload container boundary but does not by itself break container isolation or give direct host code execution. Per the CVSS vector the attack is network-reachable with no privileges (PR:N), though the independent assessment notes required user interaction (UI:R) to induce the victim to run the image; no public exploit code or confirmed in-the-wild exploitation was identified at time of analysis, and the issue is fixed in 0.6.1.
Privilege escalation in containerd's CRI checkpoint-restore path allows an authenticated local attacker who can submit an attacker-controlled checkpoint archive via CRI CreateContainer to have the restored process run with restored credentials (including root), full capabilities, and restored no_new_privs and seccomp state, while CRI status continues to report the requested ContainerConfig. The flaw affects containerd 2.1.0 through 2.2.6 and 2.3.0 through 2.3.3, and only where CRI checkpoint restore via CreateContainer is actually used; systems that never use this experimental feature are not affected. Rated CVSS 7.8 (High) with a local, low-complexity, authenticated (PR:L) vector, and no public exploit identified at time of analysis. Fixed in 2.2.7 and 2.3.4, where the restore-via-CreateContainer behavior is additionally disabled by default.
Arbitrary host file disclosure in containerd's CRI plugin lets an attacker read any file on the Kubernetes node via `kubectl logs` because the plugin restores `container.log` from a checkpoint image while blindly following a symlinked path. All containerd 2.x branches before 2.1.9, 2.2.5, and 2.3.2 are affected wherever container checkpoint/restore (CRIU-based) is used. There is no public exploit identified at time of analysis and it is not on CISA KEV, but the flaw was independently reported by numerous researchers and a vendor patch is available.
Host command execution in containerd's CRI plugin arises because labels from an image config (Dockerfile LABEL instruction) are propagated to the created container without validation; when a downstream plugin consumes those labels for operations (notably the restart-monitor's binary:// logger path), an attacker-controlled label value becomes an arbitrary command executed with host-root privileges. Affected releases are all containerd versions prior to 1.7.33, 2.0.10, 2.1.9, 2.2.5, and 2.3.2, meaning any environment that pulls and runs an untrusted image on a node using a label-consuming plugin is exposed to full container-to-host escape. No public exploit identified at time of analysis, and the issue is not listed in CISA KEV, so this is a high-severity, responsibly-disclosed flaw rather than one with confirmed active exploitation.
Kubernetes device-plugin and resource-allocation enforcement can be bypassed in containerd by a namespace user holding pod-creation rights, who restores a container from a maliciously crafted checkpoint image. The CRI restore path trusts Container Device Interface (CDI) annotations embedded in untrusted checkpoint metadata instead of the pod's create-time spec, letting the attacker smuggle arbitrary CDI edits (host device nodes and mounts) into the restored container. It affects containerd v2.1.0-2.1.8, v2.2.0-2.2.4 and v2.3.0-2.3.1; there is no public exploit identified at time of analysis and it is not listed in CISA KEV.
Repeated directory traversal during image-layer unpacking in containerd allows a malicious container image to consume excessive CPU by interleaving ordinary files with opaque whiteout markers, delaying container startup and reducing image-pull concurrency for unrelated deployments. Affected versions are containerd prior to 1.7.35, 2.0.12, 2.2.8, and 2.3.5; exploitation requires an operator, orchestrator, or CI/CD pipeline to pull or import the attacker-controlled image (CVSS 4.0 base 4.6, Medium; independent assessment CVSS 3.1 AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:L), so environments restricted to trusted, signed images from controlled registries are effectively not exposed. Only availability is affected - there is no code execution or data exposure - and no public exploit code had been identified at the time of analysis; this is a genuine but low-priority denial-of-service issue rather than a high-severity emergency.
Integer overflow in containerd overlaybd's LSMT index loader (do_load_index) lets a crafted, untrusted overlaybd blob pulled from a registry corrupt heap state and crash the host-side runtime, degrading availability for all overlaybd-backed containers on the node. Affected are overlaybd builds through 1.0.18 that are actually used as the container snapshotter/backend; exploitation is unauthenticated (CVSS PR:N) but requires high attack complexity (AC:H) - the victim must load an attacker-controlled blob in a deployment running multiple overlaybd-backed containers, which is why Scope is Changed. Impact is availability-only (C:N/I:N/A:H, CVSS 6.8); there is no public exploit identified at time of analysis and no CISA KEV confirmation, and organizations pulling only from trusted, signed sources are not realistically exposed.
Denial of service in containerd versions prior to 1.7.36, 2.0.13, 2.2.9, 2.3.6, and 2.4.1 allows an unauthenticated attacker who controls or poisons an image source to force excessive CPU and memory consumption during PullImage, causing long ContainerCreating stalls and potential node instability at larger graph sizes. The vulnerability is triggered before container start and requires no privileges on containerd itself, but is limited to environments that pull untrusted images; clusters pulling only trusted first-party images are not exposed. No public exploit identified at time of analysis, and impact is availability-only with no confidentiality or integrity effect.
Checkpoint image poisoning in containerd's CRI implementation allows an attacker with pod-creation permissions to corrupt the node-local image cache, causing victim pods to silently execute malicious images in place of legitimate ones. The root cause is missing validation of image references embedded in checkpoint image configurations: containerd trusts attacker-controlled strings in the checkpoint archive to drive image pulls and local tag assignment. Subsequent pods using an IfNotPresent or Never pull policy then inherit the poisoned tag and execute arbitrary code under the victim pod's Kubernetes identity. No active exploitation has been confirmed (not in CISA KEV), and no public exploit code has been identified at time of analysis; vendor-released patches are available.
Memory exhaustion via maliciously crafted container image in containerd causes an OOM kill of the containerd process, rendering the container runtime API unavailable and disrupting orchestration layers including Docker Engine and Kubernetes control-plane components. CVE-2026-47262 is rated Moderate by the containerd project - lower than the four co-patched Critical/High CVEs - and is fixed across the full active supported release tree in versions 2.3.2, 2.2.5, 2.1.9, 2.0.10, and 1.7.33. No public exploit code has been identified and this vulnerability is not listed in the CISA KEV catalog at time of analysis.
containerd is an open-source container runtime. Rated medium severity (CVSS 6.9), this vulnerability is no authentication required, low attack complexity. This Memory Leak vulnerability could allow attackers to exhaust available memory leading to denial of service.
containerd is an open-source container runtime. Rated high severity (CVSS 7.3), this vulnerability is low attack complexity.
containerd is an open-source container runtime. Rated medium severity (CVSS 4.6), this vulnerability is no authentication required, low attack complexity. No vendor patch available.
containerd is a container runtime. Rated high severity (CVSS 7.6), this vulnerability is remotely exploitable, no authentication required, low attack complexity.
containerd is an open-source container runtime. Rated medium severity (CVSS 4.6), this vulnerability is low attack complexity. This Integer Overflow vulnerability could allow attackers to cause unexpected behavior through arithmetic overflow.
containerd is an open source container runtime. Rated high severity (CVSS 7.8), this vulnerability is low attack complexity. Public exploit code available.
containerd is an open source container runtime. Rated medium severity (CVSS 5.5), this vulnerability is no authentication required, low attack complexity. This Allocation of Resources Without Limits vulnerability could allow attackers to exhaust system resources through uncontrolled allocation.
containerd is an open source container runtime. Rated medium severity (CVSS 6.5), this vulnerability is remotely exploitable, low attack complexity. This Uncontrolled Resource Consumption vulnerability could allow attackers to cause denial of service by exhausting system resources.
containerd is an open source container runtime. Rated medium severity (CVSS 5.5), this vulnerability is low attack complexity. No vendor patch available.
containerd is a container runtime available as a daemon for Linux and Windows. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available.
containerd is an open source container runtime with an emphasis on simplicity, robustness and portability. Rated high severity (CVSS 7.8), this vulnerability is low attack complexity. This Path Traversal vulnerability could allow attackers to access files and directories outside the intended path.
containerd is a container runtime. Rated medium severity (CVSS 6.3), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
In containerd (an industry-standard container runtime) before versions 1.3.10 and 1.4.4, containers launched through containerd's CRI implementation (through Kubernetes, crictl, or any other. Rated medium severity (CVSS 6.3), this vulnerability is remotely exploitable. This Exposure of Resource to Wrong Sphere vulnerability could allow attackers to access resources from an unintended security context.
containerd is an industry-standard container runtime and is available as a daemon for Linux and Windows. Rated medium severity (CVSS 5.2), this vulnerability is low attack complexity.
In containerd (an industry-standard container runtime) before version 1.2.14 there is a credential leaking vulnerability. Rated medium severity (CVSS 6.1), this vulnerability is remotely exploitable, no authentication required. No vendor patch available.
Native code execution inside the shim zygote process is possible in runwasi's containerd-shim-wasmtime-v1 prior to 0.6.1 when a victim pulls and runs an attacker-crafted OCI image whose single Wasm layer is actually Wasmtime precompiled (serialized native-code) bytes. Because the shim trusts precompiled-format bytes from image layers as if they came from the trusted precompile-cache path, it deserializes them without normal WebAssembly validation, yielding the filesystem, environment, credentials, networking, and Linux syscall access of the workload container; the escape reaches the workload container boundary but does not by itself break container isolation or give direct host code execution. Per the CVSS vector the attack is network-reachable with no privileges (PR:N), though the independent assessment notes required user interaction (UI:R) to induce the victim to run the image; no public exploit code or confirmed in-the-wild exploitation was identified at time of analysis, and the issue is fixed in 0.6.1.
Privilege escalation in containerd's CRI checkpoint-restore path allows an authenticated local attacker who can submit an attacker-controlled checkpoint archive via CRI CreateContainer to have the restored process run with restored credentials (including root), full capabilities, and restored no_new_privs and seccomp state, while CRI status continues to report the requested ContainerConfig. The flaw affects containerd 2.1.0 through 2.2.6 and 2.3.0 through 2.3.3, and only where CRI checkpoint restore via CreateContainer is actually used; systems that never use this experimental feature are not affected. Rated CVSS 7.8 (High) with a local, low-complexity, authenticated (PR:L) vector, and no public exploit identified at time of analysis. Fixed in 2.2.7 and 2.3.4, where the restore-via-CreateContainer behavior is additionally disabled by default.
Arbitrary host file disclosure in containerd's CRI plugin lets an attacker read any file on the Kubernetes node via `kubectl logs` because the plugin restores `container.log` from a checkpoint image while blindly following a symlinked path. All containerd 2.x branches before 2.1.9, 2.2.5, and 2.3.2 are affected wherever container checkpoint/restore (CRIU-based) is used. There is no public exploit identified at time of analysis and it is not on CISA KEV, but the flaw was independently reported by numerous researchers and a vendor patch is available.
Host command execution in containerd's CRI plugin arises because labels from an image config (Dockerfile LABEL instruction) are propagated to the created container without validation; when a downstream plugin consumes those labels for operations (notably the restart-monitor's binary:// logger path), an attacker-controlled label value becomes an arbitrary command executed with host-root privileges. Affected releases are all containerd versions prior to 1.7.33, 2.0.10, 2.1.9, 2.2.5, and 2.3.2, meaning any environment that pulls and runs an untrusted image on a node using a label-consuming plugin is exposed to full container-to-host escape. No public exploit identified at time of analysis, and the issue is not listed in CISA KEV, so this is a high-severity, responsibly-disclosed flaw rather than one with confirmed active exploitation.
Kubernetes device-plugin and resource-allocation enforcement can be bypassed in containerd by a namespace user holding pod-creation rights, who restores a container from a maliciously crafted checkpoint image. The CRI restore path trusts Container Device Interface (CDI) annotations embedded in untrusted checkpoint metadata instead of the pod's create-time spec, letting the attacker smuggle arbitrary CDI edits (host device nodes and mounts) into the restored container. It affects containerd v2.1.0-2.1.8, v2.2.0-2.2.4 and v2.3.0-2.3.1; there is no public exploit identified at time of analysis and it is not listed in CISA KEV.
Repeated directory traversal during image-layer unpacking in containerd allows a malicious container image to consume excessive CPU by interleaving ordinary files with opaque whiteout markers, delaying container startup and reducing image-pull concurrency for unrelated deployments. Affected versions are containerd prior to 1.7.35, 2.0.12, 2.2.8, and 2.3.5; exploitation requires an operator, orchestrator, or CI/CD pipeline to pull or import the attacker-controlled image (CVSS 4.0 base 4.6, Medium; independent assessment CVSS 3.1 AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:L), so environments restricted to trusted, signed images from controlled registries are effectively not exposed. Only availability is affected - there is no code execution or data exposure - and no public exploit code had been identified at the time of analysis; this is a genuine but low-priority denial-of-service issue rather than a high-severity emergency.
Integer overflow in containerd overlaybd's LSMT index loader (do_load_index) lets a crafted, untrusted overlaybd blob pulled from a registry corrupt heap state and crash the host-side runtime, degrading availability for all overlaybd-backed containers on the node. Affected are overlaybd builds through 1.0.18 that are actually used as the container snapshotter/backend; exploitation is unauthenticated (CVSS PR:N) but requires high attack complexity (AC:H) - the victim must load an attacker-controlled blob in a deployment running multiple overlaybd-backed containers, which is why Scope is Changed. Impact is availability-only (C:N/I:N/A:H, CVSS 6.8); there is no public exploit identified at time of analysis and no CISA KEV confirmation, and organizations pulling only from trusted, signed sources are not realistically exposed.
Denial of service in containerd versions prior to 1.7.36, 2.0.13, 2.2.9, 2.3.6, and 2.4.1 allows an unauthenticated attacker who controls or poisons an image source to force excessive CPU and memory consumption during PullImage, causing long ContainerCreating stalls and potential node instability at larger graph sizes. The vulnerability is triggered before container start and requires no privileges on containerd itself, but is limited to environments that pull untrusted images; clusters pulling only trusted first-party images are not exposed. No public exploit identified at time of analysis, and impact is availability-only with no confidentiality or integrity effect.
Checkpoint image poisoning in containerd's CRI implementation allows an attacker with pod-creation permissions to corrupt the node-local image cache, causing victim pods to silently execute malicious images in place of legitimate ones. The root cause is missing validation of image references embedded in checkpoint image configurations: containerd trusts attacker-controlled strings in the checkpoint archive to drive image pulls and local tag assignment. Subsequent pods using an IfNotPresent or Never pull policy then inherit the poisoned tag and execute arbitrary code under the victim pod's Kubernetes identity. No active exploitation has been confirmed (not in CISA KEV), and no public exploit code has been identified at time of analysis; vendor-released patches are available.
Memory exhaustion via maliciously crafted container image in containerd causes an OOM kill of the containerd process, rendering the container runtime API unavailable and disrupting orchestration layers including Docker Engine and Kubernetes control-plane components. CVE-2026-47262 is rated Moderate by the containerd project - lower than the four co-patched Critical/High CVEs - and is fixed across the full active supported release tree in versions 2.3.2, 2.2.5, 2.1.9, 2.0.10, and 1.7.33. No public exploit code has been identified and this vulnerability is not listed in the CISA KEV catalog at time of analysis.
containerd is an open-source container runtime. Rated medium severity (CVSS 6.9), this vulnerability is no authentication required, low attack complexity. This Memory Leak vulnerability could allow attackers to exhaust available memory leading to denial of service.
containerd is an open-source container runtime. Rated high severity (CVSS 7.3), this vulnerability is low attack complexity.
containerd is an open-source container runtime. Rated medium severity (CVSS 4.6), this vulnerability is no authentication required, low attack complexity. No vendor patch available.
containerd is a container runtime. Rated high severity (CVSS 7.6), this vulnerability is remotely exploitable, no authentication required, low attack complexity.
containerd is an open-source container runtime. Rated medium severity (CVSS 4.6), this vulnerability is low attack complexity. This Integer Overflow vulnerability could allow attackers to cause unexpected behavior through arithmetic overflow.
containerd is an open source container runtime. Rated high severity (CVSS 7.8), this vulnerability is low attack complexity. Public exploit code available.
containerd is an open source container runtime. Rated medium severity (CVSS 5.5), this vulnerability is no authentication required, low attack complexity. This Allocation of Resources Without Limits vulnerability could allow attackers to exhaust system resources through uncontrolled allocation.
containerd is an open source container runtime. Rated medium severity (CVSS 6.5), this vulnerability is remotely exploitable, low attack complexity. This Uncontrolled Resource Consumption vulnerability could allow attackers to cause denial of service by exhausting system resources.
containerd is an open source container runtime. Rated medium severity (CVSS 5.5), this vulnerability is low attack complexity. No vendor patch available.
containerd is a container runtime available as a daemon for Linux and Windows. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available.
containerd is an open source container runtime with an emphasis on simplicity, robustness and portability. Rated high severity (CVSS 7.8), this vulnerability is low attack complexity. This Path Traversal vulnerability could allow attackers to access files and directories outside the intended path.
containerd is a container runtime. Rated medium severity (CVSS 6.3), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
In containerd (an industry-standard container runtime) before versions 1.3.10 and 1.4.4, containers launched through containerd's CRI implementation (through Kubernetes, crictl, or any other. Rated medium severity (CVSS 6.3), this vulnerability is remotely exploitable. This Exposure of Resource to Wrong Sphere vulnerability could allow attackers to access resources from an unintended security context.
containerd is an industry-standard container runtime and is available as a daemon for Linux and Windows. Rated medium severity (CVSS 5.2), this vulnerability is low attack complexity.
In containerd (an industry-standard container runtime) before version 1.2.14 there is a credential leaking vulnerability. Rated medium severity (CVSS 6.1), this vulnerability is remotely exploitable, no authentication required. No vendor patch available.