GPU VulnDB

Database/Container, Kubernetes & orchestration

runwasi wasmtime shim: crafted OCI layer is deserialized as native code, escaping the WASI sandbox

CVSS 9.3CVE-2026-47218Container, Kubernetes & orchestrationcurated

Impact

A tenant who can get a crafted image scheduled gets native code execution inside the shim zygote process, bypassing WebAssembly validation entirely. The code runs with the filesystem, environment, credentials, networking and syscall access of the workload container, so any mounted service-account token, registry pull secret or node-local credential in that container's view is exposed. On a GPU fleet that runs Wasm workloads alongside CUDA pods, this collapses the Wasm sandbox boundary down to the container boundary - the advisory is explicit that it does not by itself break container isolation or give host code execution. Downstream shims built on runwasi's containerd-shim-wasm precompile-cache API are affected too if they implement Compiler and trust precompiled artifacts from image layers.

Who can reach it

Anyone who can cause a node to pull and run a chosen image - an untrusted tenant with image-pull rights, or a compromised registry entry. No authentication to the shim itself is needed; the image is the payload.

What to do

Upgrade containerd-shim-wasmtime to 0.6.1 and restart the shim on each node; running Wasm tasks are restarted, GPU/CUDA pods on the same node are not affected and no reboot is required. The 0.6.1 boundary covers containerd-shim-wasmtime only - operators running a downstream shim built on the precompile-cache API must get a fixed build from that vendor. Until patched, restrict which images may run on the Wasm shim runtime class to trusted registries.

References

Related entries

All Container, Kubernetes & orchestration entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.