Wasmtime patches Winch compiler sandbox-escaping memory access
TL;DR — A Critical bug in Wasmtime’s non-default Winch compiler can let a crafted WebAssembly guest read/write outside its linear-memory sandbox, potentially exposing host memory and enabling in-process compromise.
What happened
Wasmtime is a widely used WebAssembly (Wasm) runtime that executes untrusted Wasm modules with sandboxing guarantees. A GitHub Security Advisory (GHSA-xx5w-cvp6-jv83) discloses a Critical vulnerability where Wasmtime’s Winch (baseline) compiler backend may generate code that allows a properly constructed guest Wasm module to access memory before/after the guest’s linear-memory region.
The advisory notes this issue requires running Wasmtime with the Winch compiler (-Ccompiler=winch); Wasmtime defaults to Cranelift instead. The aarch64 case has an observed-working proof of concept; the x86-64 case is described as theoretical and may not be reachable in practice. Impact ranges from host process crash (DoS) to arbitrary data leak, and (with a write primitive) potential arbitrary RCE within the host process.
| Item | Source value |
|---|---|
| Affected software | wasmtime (cargo package) |
| Severity | Critical; CVSS v4.0 overall score 9.0 |
| Affected versions | >= 25.0.0, <= 36.0.6 ; >= 37.0.0, <= 42.0.1 ; 43.0.0 |
| Patched versions | 36.0.7, 42.0.2, 43.0.1 |
This is an especially important class of issue for platform teams using Wasm for tenant isolation, plugin execution, policy engines, or “untrusted code” workloads: compiler miscompilations that weaken bounds checks can convert “sandboxed guest code” into “in-process memory access.”
Who is impacted
- Deployments running
wasmtimewith Winch enabled (explicitly using-Ccompiler=winch). - Projects on any of the affected version ranges listed in the advisory.
- Higher-risk environments where Wasm modules are attacker-controlled or come from a less-trusted tenant boundary (multi-tenant runtimes, extensibility/plugin systems, user-supplied Wasm, policy engines executing third-party Wasm).
- Per the advisory: aarch64 has an observed-working PoC; x86-64 impact is stated as theoretical and may not be reachable in practice.
What to do now
- Follow vendor remediation guidance and apply a patched release.
"Wasmtime 43.0.1, 42.0.2, and 36.0.7 have been released with fixes for this issue."
- If you cannot upgrade immediately, avoid using Winch and run Wasmtime with the default Cranelift backend.
"Users of Wasmtime are encouraged either to upgrade to patched versions or, if that is not possible, use the Cranelift compiler backend."
- Inventory where
-Ccompiler=winchis enabled (flags, config, build scripts, container images, and embedded Wasmtime integrations) and treat those deployments as the priority patch set. - If you run multi-tenant Wasm or accept third-party Wasm modules, treat this as a potential sandbox boundary failure: review exposure, tighten module provenance controls, and consider additional isolation layers (process/container/VM) where feasible until patched.
Content is AI-assisted and reviewed by our team, but issues may be missed and best practices evolve rapidly, send corrections to [email protected]. Always consult official documentation and validate key implementation decisions before making design or security choices.