The Bytecode Alliance has disclosed two critical sandbox-escape vulnerabilities in Wasmtime, the widely embedded WebAssembly runtime, both rooted in Cranelift, its default code generator. CVE-2026-115889 affects all architectures; CVE-2026-115893 affects only aarch64 (ARM64). Both are rated CVSS v3.1 9.9, and fixes were released on October 19, 2026. We found no reports of in-the-wild exploitation as of publication.

Technical details

Both bugs are compiler correctness failures: the guest’s WebAssembly is valid and passes validation, but the machine code Cranelift emits does not preserve the sandbox’s guarantees.

  • CVE-2026-115889 (all architectures): Cranelift packed certain value indices into 24-bit fields. In release builds, a number too large for its field overflowed silently instead of failing compilation. A sufficiently large, attacker-shaped module can therefore cause the compiler to confuse values, producing code that can read or write outside the guest’s linear memory.
  • CVE-2026-115893 (aarch64 only, GHSA-mghf-wjfp-p5xm, RUSTSEC-2026-0379): When a single br_table instruction has more than roughly 256,000 targets, the default target falls outside the range the aarch64 backend can encode, and the branch offset wraps silently. Control flow then jumps to an incorrect target inside the generated code.

Exploitation requires the attacker to get a crafted module compiled by the victim’s Wasmtime. Escaping the sandbox gives the module host-process memory access, so the impact depends on what the embedding process holds: credentials, tenant data, or other tenants’ state.

Who is affected

Any service that compiles and runs WebAssembly it did not author: serverless and edge function platforms, plugin systems, multi-tenant “run user code” backends, CI sandboxes, and data-processing pipelines that accept user-supplied modules. Services that only run modules you build and control from trusted sources face far lower risk. The multi-tenant case is the severe one, since a single malicious tenant could reach co-resident workloads in the same process.

Version ranges differ between secondary sources, so confirm against the primary advisories. Per RustSec, patched releases for the aarch64 br_table bug are 36.0.19, 48.0.7, and 49.0.4 or later. Ostorlab notes that 43.0.0 through 48.0.6 and 49.0.0 through 49.0.3 remain vulnerable to that bug. Fixed releases listed for the series are 36.0.19, 48.0.7, 49.0.4, and 50.0.0. Release lines not listed received no backport, including the 24.x LTS line, whose support ended August 20, 2026. The Bytecode Alliance’s earlier Cranelift aarch64 sandbox-escape advisories from April 2026 are a separate set of bugs.

Mitigation

  1. Upgrade Wasmtime to a fixed release for your line (36.0.19, 48.0.7, 49.0.4, or 50.0.0). Rebuild and redeploy anything that statically links the wasmtime crate or embeds it via language bindings (Python, Go, .NET, etc.); updating a system package does not fix vendored copies.
  2. Inventory embedders. Run cargo tree -i wasmtime and cargo audit against your repos; RUSTSEC-2026-0379 is in the advisory database. Check downstream products that bundle Wasmtime and watch for vendor updates.
  3. Lines without a fix (including 24.x and other end-of-life releases) must be moved to a supported version; there is no documented workaround for either CVE.
  4. Defense in depth: run the runtime host in a separate process or microVM per tenant, drop privileges and syscalls (seccomp, gVisor, Firecracker), and keep secrets out of processes that execute untrusted modules. A runtime escape should land in a sandbox that has nothing worth stealing.
  5. Limit module shape where feasible: reject modules with extreme br_table sizes or very large function bodies as a stopgap while patching, understanding this is not a complete fix for the all-architecture bug.

References