Skip to main content

containerd-shim-wasmtime EUVDEUVD-2026-102247

| CVE-2026-47218 CRITICAL
Deserialization of Untrusted Data (CWE-502)
2026-10-15 GitHub_M
9.3
CVSS 4.0 · Vendor: GitHub_M
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Access
    Craft OCI image with precompiled wasmtime layer
  2. Delivery
    Deliver image via registry to victim
  3. Exploit
    Victim runs image on wasmtime shim (<0.6.1)
  4. Execution
    Shim deserializes bytes as native code
  5. Impact
    Execute code with workload container privileges

Vulnerability Assessment

Weakness
CWE
OWASP Top 10:2025
A08:2025 - Software or Data Integrity Failures
ASVS 5.0
V1 - Encoding and Sanitization Safe deserialization, type allowlists
MITRE ATT&CK

2 techniques across 2 tactics: Execution, Initial Access

The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up.

Exploitation Conditions

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.

Impact

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.

Exploit ScenarioDerived

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.

Act Now Prioritize within 24-48h. Why: CRITICAL severity.
Patch available 0.4% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – Oct 15, 2026

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.

RemediationAI

Vendor-released patch: upgrade to containerd-shim-wasmtime v0.6.1 (runwasi 0.6.1), which introduces the precompiled trust flag and rejects OCI layers that claim or resemble precompiled content - see the advisory at https://github.com/containerd/runwasi/security/advisories/GHSA-cc25-vq59-rcjx, the fix commit d28ab73c2c8a6c50d1927078821bd418b9e51638, and the release at https://github.com/containerd/runwasi/releases/tag/containerd-shim-wasmtime/v0.6.1. Downstream shims built on runwasi's precompile-cache API must port the same change and validate their own releases independently, since 0.6.1 certifies only containerd-shim-wasmtime. Compensating controls, with trade-offs: (1) Only run Wasm images built and signed by trusted internal pipelines and enforce image-signature/admission policy at the registry or kubelet level, which prevents the untrusted-image precondition but breaks any legitimate use of third-party images; (2) treat all OCI pull credentials and registry access as high-value, given the attacker must induce the victim to run a crafted image via registry compromise, supply chain, or social engineering - locking down registry write access and provenance reduces that vector at the cost of flexibility; (3) if patching is delayed, disable or avoid the shim's precompile-cache path for untrusted workloads (do not mount/populate a shared precompile cache and force fresh compilation from Wasm sources), which removes the deserialization of cached native code but increases startup latency and CPU cost; (4) because the flaw is reachable purely by running an image, treat any image that has passed through the vulnerable shim prior to 0.6.1 as potentially compromised within its container boundary and rotate workload-scoped secrets and credentials accordingly.

Affected VersionsENISA

runwasi < 0.6.1

Affected Packages

euvd runwasi fix: 0.6.1

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 1 package in euvd

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Technical ContextAI · show details

runwasi provides containerd shims that run Wasm/WASI workloads as containers. The affected component is containerd-shim-wasmtime-v1, which uses the Wasmtime runtime and its precompiled-module cache: for performance, previously compiled Wasm is stored as serialized native code (a Wasmtime "precompiled" artifact) and reloaded, which is a trusted-artifact deserialization path. The root-cause class is CWE-502 (Deserialization of Untrusted Data). Prior to 0.6.1 the shim's loading logic (see crates/containerd-shim-wasmtime/src/instance.rs) classified any binary that matched wasmtime::Engine::detect_precompiled() as "already precompiled" and pushed it through the precompiled/cache branch - regardless of whether it came from the trusted containerd cache or from an OCI image layer. An attacker could therefore ship a crafted OCI image whose layer uses a Wasm media type (e.g. application/vnd.bytecodealliance.wasm.component.layer.v0+wasm) but whose bytes are a valid Wasmtime serialized artifact; detect_precompiled matched, normal Wasm validation was skipped, and the native code was deserialized and executed in the shim zygote process. The upstream fix (commit d28ab73c2c8a6c50d1927078821bd418b9e51638) threads a new precompiled: bool flag through containerd-shim-wasm's Source/Client code: layers fetched from the containerd precompile cache are marked precompiled=true while OCI image modules are marked false. The sandbox now calls is_precompiled() to decide the path; a layer marked precompiled that does not detect as a valid precompiled artifact is rejected, and non-precompiled OCI content that fails module/component parsing raises "invalid wasm module" instead of falling back to deserialization. A regression test, test_oci_image_with_precompiled_bytes_is_rejected, asserts that precompiled bytes delivered via an OCI layer are refused. Note the trust-boundary scoping: the 0.6.1 fix certifies containerd-shim-wasmtime only, and any downstream shim built on runwasi's containerd-shim-wasm precompile-cache API that implements Compiler and trusts executable precompiled artifacts from OCI image layers is exposed to the same pattern until it patches independently.

Know when Runwasi gets its next vulnerability

  • Watch products and get an email when something new is published
  • Check this CVE against your own stack and servers
  • Exploit and PoC references, threat intelligence from 22 sources

No credit card · 7-day full trial

Severity by source

Vendor (GitHub_M) PRIMARY 9.3 CRITICAL
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
vuln.today AI 9.6 CRITICAL

Crafted image is delivered over the network with no attacker privileges but the victim must run it (UI:R); escaping the WASI sandbox into the container is a scope change (S:C) with full container-level C/I/A impact.

3.1 AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H
4.0 AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

Primary rating from Vendor (GitHub_M).

CVSS VectorVendor: GitHub_M

Attack Vector
Network
Attack Complexity
Low
Attack Requirements
None
Privileges Required
None
User Interaction
None
Vulnerable system: Confidentiality
High
Vulnerable system: Integrity
High
Vulnerable system: Availability
High
Subsequent system: Confidentiality
None
Subsequent system: Integrity
None
Subsequent system: Availability
None

Lifecycle Timeline

2
Patch available
Oct 15, 2026 - 19:18 EUVD
CVE Published
Oct 15, 2026 - 18:16 cve.org
CRITICAL 9.3

DescriptionCVE.org

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.

Technical POC Analysis

Bug class: CWE-502, Deserialization of Untrusted Data.

Full technical POC analysis - root cause, step-by-step exploitation and patch breakdown - is part of the Pro and Business plans.

Executive ViewAI

Why It Matters

runwasi's containerd-shim-wasmtime-v1, the component that runs WebAssembly workloads under containerd, can be induced to execute attacker-supplied native code inside the workload container whenever an operator pulls and runs a tainted OCI image. Teams running Wasm workloads on affected versions expose the container's filesystem, environment, credentials and network access to an attacker, creating data-access and lateral-movement risk through ordinary image-pull workflows; the analysis indicates the escape stops at the workload container boundary rather than reaching the host directly. No vendor-released patch or public exploit was identified at time of analysis, so near-term risk is governed by image provenance, operator discipline and whatever interim controls leadership authorizes.

Business Impact: High
Compensating Controls

No vendor-released patch identified at time of analysis. Interim mitigations: block pulls of unsigned or unverified OCI images and enforce a trusted-registry allowlist; treat precompiled/serialized Wasm layers as untrusted and reject them at admission where feasible; run affected Wasm workloads with least-privilege credentials, restricted egress, read-only filesystems and no long-lived secrets; segment Wasm workload networks to limit lateral movement; monitor shim zygote processes for unexpected syscalls, child processes or network activity; and restrict who can push or run Wasm images until a fixed containerd-shim-wasmtime-v1 release is validated and deployed.

Threat Intelligence Overview

EPSS Score
0.4%
Top 68% exploitable
Prevalence
Low
niche Wasm-on-containerd shim, limited production deployment footprint
Data Quality
6 sources
Confidence: High

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue
Severity CRITICAL
CISA KEV No
Public POC No
EPSS 0.4%
Patch available Yes
Active threat No
Deciding rule
CRITICAL severity
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision
Scheduled
Exploitation
None
System Exposure· derived
Open
Automatable
Yes
Human Impact
High
Technical Impact
Total

Priority Score

46
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +46
PoC: 0
Weaponized: 0
Threat intel: 0
Gov advisory: 0

Attack Technique

Insecure deserialization occurs when an application converts serialized data (a stream of bytes representing an object's state) back into a living object without proper validation.

Remote Code Execution represents the critical moment when an attacker successfully runs arbitrary code on a target system without physical access.

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy