By ByteBot
Two critical Wasmtime Cranelift sandbox escape vulnerabilities — both scored CVSS 9.9 — let a crafted WebAssembly module break out of its runtime and execute host-level code. The Bytecode Alliance patched both on October 19–20, 2026. One already has a working public exploit on GitHub.
If you have wasmtime anywhere in a Cargo.lock, or run a platform that executes user-supplied Wasm, check your versions today. A previous GitLab CVSS 10.0 RCE showed how quickly high-severity compiler-chain vulnerabilities get exploited — this one has a public proof of concept already posted.
CVE-2026-115889: When 24 Bits Is Not Enough (All Architectures)
Cranelift, Wasmtime’s JIT compiler, tracks intermediate values using SSA — Static Single Assignment form. Before Wasmtime 43, those SSA value indices were packed into 24-bit fields inside 64-bit words. The packing code shifts the value into place and ORs it in without masking off the high bits.
In debug builds, an assertion panics if you hit the limit. In release builds — the ones running in production — the overflow is silent. Bits spill into adjacent fields. Cranelift references the wrong value. The compiler produces incorrect machine code that can cause type confusion, and the Wasm module is no longer contained.
Triggering this requires pushing past 2^24 − 1 SSA values (roughly 16.7 million) in a single function — crafted input, not accidental. The fix landed in Wasmtime 43.0.0 in March 2026, switching to full u32 indices with explicit overflow checks. The 36.x LTS branch got the backport in 36.0.19 on October 19, 2026.
CVE-2026-115893: The Branch Table That Jumps Anywhere (aarch64)
This one is more surgical and already has a full public proof of concept on GitHub.
WebAssembly’s br_table instruction is a switch statement that dispatches to many targets. On aarch64, Cranelift compiles large br_tables into a JTSequence — a jump table with a conditional branch as its default path. When that table grows past roughly 256,000 entries, the default branch’s displacement overflows the encoding range of the aarch64 B.cond instruction. The offset wraps silently. Instead of jumping to the intended default target, the branch lands at an attacker-influenced offset inside the JIT memory region.
The published exploit demonstrates the miscompiled branch landing in an executable JIT literal pool and executing an aarch64 payload that makes a host syscall — entirely outside the Wasm sandbox. This is particularly relevant for Wasmtime deployments on Apple Silicon or AWS Graviton.
Who Is Actually Exposed
The attack surface is specific: you need to be running Wasmtime to compile and execute Wasm modules you do not fully control. The highest-risk scenarios:
- Edge runtimes — Fastly Compute runs every customer request through a Wasmtime-sandboxed module. That is the exact multi-tenant attack surface these CVEs target.
- Plugin systems — Any application accepting Wasm plugins from external sources needs to update immediately.
- Rust projects with embedded Wasmtime — The JavaScript transpiler SWC embeds Wasmtime and has already shipped a patched version. Check your transitive dependencies.
Applications that only compile and run Wasm they produce themselves have significantly lower exposure. The same supply-chain caution that applies to TLS cipher deprecations applies here: the dependency may be several levels deep.
Wasmtime Cranelift Sandbox Escape: Patch Matrix and Commands
| Branch | Affected Through | Patch To |
|---|---|---|
| 36.x LTS | 36.0.18 | 36.0.19 |
| 37.x to 47.x | All versions | Upgrade to 48.x+ |
| 48.x | 48.0.6 | 48.0.7 |
| 49.x | 49.0.3 | 49.0.4 |
| 50.x+ | Not affected | — |
Find Wasmtime in your dependency tree first:
cargo tree -i wasmtimeThen update and verify:
cargo update -p wasmtime --precise 50.0.0
cargo auditFor container and binary scanning, wasmtime-sweep finds embedded Wasmtime engines across binaries, Python wheels, NuGet packages, and container layers and flags CVE exposure automatically.
No active exploitation has been reported, and neither CVE appears in the CISA KEV catalog. But CVE-2026-115893 has a working public exploit, and the 36.x LTS patch landed less than two weeks ago. The window is narrow.
The Uncomfortable Truth About Compiler Bugs
Compiler bugs are uniquely unsettling in the security world. You can audit your Wasm module line by line and still be vulnerable. The sandbox guarantee does not come from the Wasm source code — it comes from the runtime’s ability to compile it correctly. When the JIT produces wrong machine code, that guarantee disappears regardless of what the source says.
These CVEs expose a layer most developers do not think about. Update Wasmtime, scan your supply chain, and confirm your platform provider has patched their runtime. This one should not sit on the backlog.
