[CRITICAL] Security Advisory: Wasmtime: Miscompiled guest heap access enables sandbox escape on aarch64 Cranelift (wasmtime, wasmtime, wasmtime)

Wasmtime users on aarch64 (ARM64) face a critical sandbox escape vulnerability in the Cranelift compiler backend. A miscompilation bug lets WebAssembly guests read and write arbitrary host memory, bypassing all protections. Update to Wasmtime 36.0.7, 42.0.2, or 43.0.1 immediately if you run Cranelift on ARM64 with 64-bit WebAssembly memories enabled—which is the default.

This flaw hits when Cranelift generates code for heap loads of the form load(iadd(base, ishl(index, amt))), where amt is a constant shift amount. Cranelift incorrectly masks the shift value during instruction selection, matching a wrong lowering rule. The guest computes one address for bounds checking (which passes) but loads from a different, often much larger address that wraps around due to 64-bit overflow. Result: arbitrary read/write primitives against host memory.

Who Gets Hit

The bug requires specific conditions, narrowing its blast radius but not eliminating the risk:

• aarch64 architecture only. x86_64, RISC-V, and others using Cranelift remain safe.
• 64-bit WebAssembly linear memories (Config::wasm_memory64 enabled, default since Wasmtime 12.0 in 2023).
• Spectre mitigations and signals-based traps disabled. Spectre guards (default) block the faulty code pattern; disabling them for performance exposes you.

32-bit Wasm memories dodge it entirely. If you stick to them or run on non-ARM64, you’re fine. But ARM64 dominates cloud: AWS Graviton, Google Tau, Apple M-series. Serverless platforms like Fermyon Spin, Fastly’s edge compute, and Deno use Wasmtime—check your stack.

Proof-of-concept exploits exist. Attackers craft Wasm modules with explicit bounds checks that pass, then pivot to host data. No privileges needed beyond loading the module. In multi-tenant setups, one bad guest owns the host.

Technical Breakdown

Cranelift, Wasmtime’s default backend since 2020, optimizes Wasm to native code fast. It failed here on shift-masked addressing. The mask bug misfires pattern matching, generating ARM64 instructions that ignore overflow correctly in bounds checks but not loads.

For context, WebAssembly sandboxes isolate guest code via linear memory and traps. Memory64 (proposal merged 2023) supports >4GB heaps for real apps. Without mitigations, a guest like:

;; Simplified exploit shape
(i32.store
  (i64.add
    (i64.shl (i64.const large_index) (i64.const 12))  ;; Miscompiled shift
    (global.get base))
  (i32.const attacker_data))

Checks bounds on a wrapped-small address but stores to host memory. CVE pending, disclosed responsibly to Bytecode Alliance (Wasmtime maintainers).

Skeptical note: Cranelift’s speed-first design invites such edges. RISC-V and x86 avoided this via different lowering. Wasmtime’s multi-backend (LLVM fallback exists but slower) shines here—switch if patching lags.

Fixes and Next Steps

Patches landed: 36.0.7 (LTS), 42.0.2, 43.0.1. They fix the mask logic in Cranelift’s AArch64 backend. Update via Cargo:

$ cargo update wasmtime --precise 43.0.1

or equivalent for your distro/package manager.

Workarounds if patching delays:

• Disable wasm_memory64: Config::new().wasm_memory64(false). Limits memory to 32-bit, fine for many but breaks large-heap apps.
• Enable Spectre mitigations explicitly: Config::new().cranelift_spectre_mitigation(true) (default anyway).
• Use non-Cranelift backend: Config::new().cranelift_flag(false) falls back to slower singlepass.
• Avoid aarch64 Cranelift entirely—run x86 if possible.

Restart services post-update. Audit logs for anomalous host memory access.

Why This Matters

WebAssembly promised secure, portable code for browsers to clouds. Runtimes like Wasmtime power Kubernetes Wasm plugins, edge functions, even OS kernels (via wasmtime-wasi). A sandbox escape torches that trust model. On ARM64 servers (30%+ of AWS EC2), unpatched deployments risk full compromise.

It’s not theoretical: Wasm adoption surges—Cloudflare Workers, Wasmer, even Rust’s stdlib eyes it. This bug underscores runtime fragility at scale. Maintainers reacted fast (patches same-day), but defaults bit users. Fair play: conditions limit it, but enabling memory64 sans mitigations? Reckless for prod.

Action item: Inventory Wasmtime deps, patch, monitor upstream. Wasm’s secure-by-default pitch holds if you stay vigilant. This escape proves why.