CVE-2026-47218 in runwasi
Summary
by MITRE • 10/15/2026
runwasi facilitates running Wasm and WASI workloads managed by containerd. Prior to 0.6.1, containerd-shim-wasmtime-v1 can treat Wasmtime precompiled bytes supplied directly in an OCI image layer as a trusted artifact from the precompile-cache path and deserialize them as native code. An attacker who causes a victim to run a crafted image can bypass WebAssembly validation and execute native code in the shim zygote process, gaining the filesystem, environment, credentials, networking, and Linux syscall access available to the workload container. Downstream shims built with runwasi's containerd-shim-wasm precompile-cache API are also affected if they implement Compiler and trust executable precompiled artifacts from OCI image layers; the 0.6.1 boundary applies specifically to containerd-shim-wasmtime and does not independently certify downstream product releases. The flaw escapes the WASI sandbox to the workload container boundary, but it does not by itself bypass container isolation or provide direct host code execution. This issue is fixed in version 0.6.1.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/15/2026
The vulnerability identified in runwasi prior to version 0.6.1 represents a critical failure in the trust boundaries between WebAssembly runtime environments and their underlying system containers. Runwasi serves as an interface that facilitates the execution of Wasm and WASI workloads managed by containerd, effectively bridging the gap between lightweight virtualization technologies and traditional container orchestration. The core flaw resides within the containerd-shim-wasmtime-v1 component, which is responsible for managing the lifecycle of these WebAssembly instances. Specifically, the vulnerability allows an attacker to exploit how precompiled artifacts are handled during image processing. When a crafted OCI image layer contains Wasmtime precompiled bytes supplied directly rather than through the intended secure pathways, the shim incorrectly treats this data as a trusted artifact from the precompile-cache path. This misclassification leads the system to deserialize these maliciously constructed bytes and execute them as native code within the shim zygote process.
From a technical perspective, this flaw constitutes a severe bypass of WebAssembly validation mechanisms. Normally, WebAssembly is designed with strong isolation guarantees that prevent arbitrary memory access or host interaction unless explicitly permitted by the sandboxed environment. However, by tricking the runtime into accepting precompiled native code as valid input, an attacker effectively circumvents these safety checks. The execution context for this malicious code is the shim zygote process, which operates at a higher privilege level than the isolated WebAssembly module itself. Consequently, once executed, the payload gains access to the filesystem, environment variables, credentials, networking capabilities, and Linux system calls available to the workload container. This escalation allows an attacker who causes a victim to run a crafted image to escape the intended WASI sandbox boundary and operate with the permissions of the host container process.
The operational impact of this vulnerability is significant for any infrastructure relying on WebAssembly workloads within Kubernetes or other container orchestration platforms that utilize runwasi. An adversary can leverage this flaw to compromise the integrity and confidentiality of the workload environment. Since the shim zygote shares resources with the container, successful exploitation provides lateral movement opportunities within the cluster if proper network policies are not enforced. It is important to note that while this issue escapes the WASI sandbox to the workload container boundary, it does not by itself bypass full container isolation or provide direct host code execution on the underlying node. The attack vector remains confined to the privileges granted to the specific container instance, although these privileges can be substantial depending on how the container is configured.
This vulnerability affects downstream shims built with runwasi's containerd-shim-wasm precompile-cache API if they implement Compiler functionality and trust executable precompiled artifacts from OCI image layers in a similar manner. The fix boundary at version 0.6.1 applies specifically to containerd-shim-wasmtime, meaning that other implementations or downstream products are not independently certified as secure by this specific release note. Organizations must verify the versions of all shim components they employ and ensure that any custom builds adhere to strict validation protocols for precompiled artifacts. To mitigate this risk, administrators should immediately upgrade to version 0.6.1 or later where applicable. Additionally, implementing image scanning policies that detect unauthorized modifications to OCI layers and enforcing least-privilege configurations for container runtimes can further reduce the attack surface.
In terms of industry standards classification, this vulnerability aligns with CWE-94 Improper Control of Generation of Code (Code Injection) due to the execution of untrusted code as native instructions. It also relates to CWE-287 Improvement Authentication and CWE-269 Privilege Escalation because it involves bypassing validation checks to gain elevated access within the container context. From a threat modeling perspective, such an attack vector is consistent with MITRE ATT&CK techniques involving Initial Access through supply chain compromise or execution via system services, specifically targeting runtime environments. The failure lies in the improper trust of external inputs without sufficient integrity verification, highlighting the need for robust input validation and secure deserialization practices in containerized WebAssembly runtimes.