containerd-shim-wasmtime CVE-2026-47218

Requires a victim to pull and run an attacker-crafted OCI image on containerd-shim-wasmtime-v1 prior to 0.6.1 (or on a downstream shim built with runwasi's containerd-shim-wasm precompile-cache API that implements Compiler and trusts executable precompiled artifacts from OCI image layers). The malicious image must contain a single Wasm layer whose content is in Wasmtime precompiled/serialized (native-code) format so that detect_precompiled matches and the shim deserializes it. Limiting factors that reduce realistic risk: the attacker must induce the victim to run an untrusted image (registry compromise, supply-chain, or social engineering), so deployments running only trusted internally-built images are not exposed; the flaw stops at the workload container boundary and does not by itself escape container isolation or reach the host; and it is remediated in 0.6.1. Only the wasmtime shim's 0.6.1 release is certified fixed - downstream products must patch independently.

The vendor CVSS 4.0 base score of 9.3 (AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H) rates this Critical, driven by high confidentiality, integrity, and availability impact from native-code execution. However, the raw score overstates spray-and-pray risk: exploitation is not a direct remote-service attack but requires a victim to run an attacker-crafted OCI image, making this effectively a supply-chain / untrusted-image problem rather than an internet-facing RCE. This is a conflict worth flagging: the vector claims UI:N, yet the description explicitly states 'an attacker who causes a victim to run a crafted image,' which is user/operator interaction - real-world triggering depends on an organization pulling and running an untrusted or compromised image. The description also bounds the blast radius: the flaw escapes the WASI/Wasmtime sandbox only to the workload container boundary and does NOT bypass container isolation or yield host code execution, so it is a sandbox-escape, not a container-escape. No EPSS score, no CISA KEV listing, and no public exploit were provided in the input, so there is no public exploit identified at time of analysis and no evidence of active exploitation - the fix commit includes only a defensive regression test, not a weaponized PoC. Net: a genuine high-severity issue for anyone running Wasm workloads from untrusted registries on the wasmtime shim, but materially lower practical risk for deployments that run only trusted, internally-built images.

An attacker publishes (or compromises a registry to serve) a malicious OCI image whose single Wasm layer contains Wasmtime precompiled/serialized bytes instead of a real Wasm module. When a victim runs this image on containerd-shim-wasmtime-v1 prior to 0.6.1, the shim trusts the bytes as a precompile-cache artifact and deserializes them as native code, bypassing WebAssembly validation and executing attacker code in the shim zygote with the workload container's filesystem, environment, credential, network, and syscall access. No public exploit was provided, though the fix's regression test demonstrates the rejection path and the deserialization primitive is well understood.