Skip to content
Hacker Posts

Wasmtime patches two critical Cranelift sandbox escapes

Wasmtime shipped 50.0.0 to fix CVE-2026-115889 and CVE-2026-115893, twin 9.9 Cranelift flaws that let malicious WebAssembly modules escape the host sandbox.

Published 3 min read
cvewasmtimewebassemblybytecode-alliance

The Bytecode Alliance has patched two critical flaws in Wasmtime's Cranelift code generator, both scored 9.9, that let a malicious WebAssembly module break out of the runtime's sandbox and corrupt host memory. The advisories — GHSA-897f-g5gm-fmxm (CVE-2026-115889) and GHSA-mghf-wjfp-p5xm (CVE-2026-115893) — went out October 19, with fixed releases the next day. The maintainers report no known attacks, and neither flaw is in CISA's KEV catalog as of October 26.

What the bugs do

Both are Cranelift miscompilations: the just-in-time compiler emits wrong machine code, so the sandbox that is supposed to contain guest WebAssembly no longer holds.

  • CVE-2026-115889 — a numeric-truncation error (CWE-197) in Cranelift's value-tracking fields produces incorrect code and type confusion (CWE-843). It affects all architectures. The advisory notes Wasmtime v43 reworked Cranelift to use a full u32 index, which removes the defect structurally; the 9.9 vector is CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H.
  • CVE-2026-115893 — an out-of-range br_table index takes a branch that cannot reach the default target, so execution jumps to the wrong location. This one is specific to ARM64 (aarch64) hosts.

Wasmtime is embedded as a library, so the vulnerable code runs inside whatever program links it — edge runtimes, plugin hosts, serverless platforms. There is no configuration workaround; the fix is a rebuild.

Affected and fixed versions

CVE-2026-115889 affects releases before 36.0.19 (including the 24.x line) and 37.0.0 through 42.x; 43.0.0 and later are not affected. CVE-2026-115893 reaches further: before 36.0.19, 37.0.0 through 42.x, 43.0.0 through 47.x, 48.0.0 through 48.0.6, and 49.0.0 through 49.0.3.

Fixed releases, covering both flaws, are 36.0.19 (the 36.x LTS), 48.0.7, 49.0.4, and 50.0.0 (released October 20). The RustSec advisories are RUSTSEC-2026-0380 and RUSTSEC-2026-0379. The 24.x LTS line reached end of support on August 20, 2026, and gets no fix.

Action checklist

  1. Inventory what embeds Wasmtime. Check your own Cargo.lock and any dependency that pulls wasmtime; the vulnerable code ships inside your binary, not a separate service.
  2. Upgrade to a fixed release on your line: 36.0.19, 48.0.7, 49.0.4, or 50.0.0. Rebuild and redeploy — a package bump alone does nothing until the host is recompiled.
  3. If you are on the 24.x LTS, move off it. It is end-of-life and will not be patched.
  4. ARM64 hosts carry both flaws across a wider range; treat aarch64 deployments on 43.x–49.0.3 as exposed to CVE-2026-115893 even if you thought you were clear after v43.

Context

Sandbox-escape bugs in WebAssembly runtimes land squarely on the people who adopted Wasm precisely for isolation — CDNs, plugin systems, and multi-tenant compute that run untrusted modules. The pattern here is the familiar one for JIT compilers: the security boundary is only as sound as the code the compiler emits, and a single integer-width mistake in value tracking collapses it. Both advisories ship exact affected ranges and fixed versions rather than a vague "update now," which is the standard embedders should hold their other dependencies to.

Related stories