Wasmtime Sandbox Escape Flaws Patched in Cranelift
Two critical Wasmtime sandbox escape flaws, CVE-2026-115889 and CVE-2026-115893, let a crafted WebAssembly (Wasm) module push the Cranelift compiler into generating unsafe machine code. The Bytecode Alliance fixed both on October 19, 2026, and rated each 9.9 under CVSS v3.1.
Platforms that compile Wasm from customers or other outside parties carry the most risk, because they depend on Wasmtime to keep that code contained. One flaw affects every architecture, while the other hits ARM64 (aarch64) hosts running default settings. No exploitation has been reported, and neither advisory offers a workaround, so upgrading is the only real fix.
Two Compiler Bugs Behind the Wasmtime Sandbox Escape
Wasmtime is the Bytecode Alliance’s WebAssembly runtime, and Cranelift is the default compiler it uses to turn Wasm bytecode into native machine code. Isolation depends on that generated code doing exactly what the Wasm allows, so a compiler mistake can break the sandbox even when the rest of the runtime works correctly.
Both flaws follow that pattern, though they fail in different places. The comparison below shows how they differ.
| Detail | CVE-2026-115889 | CVE-2026-115893 |
|---|---|---|
| Advisory | GHSA-897f-g5gm-fmxm | GHSA-mghf-wjfp-p5xm |
| Root Cause | Silent overflow of 24-bit SSA value indices | Out-of-range default branch in very large br_table sequences |
| Architectures | All | ARM64 (aarch64) only |
| CVSS v3.1 | 9.9 Critical | 9.9 Critical |
| CWE | CWE-197 (Numeric Truncation Error), CWE-843 (Type Confusion) | CWE-691 (Insufficient Control Flow Management) |
| CVE Record | Published October 23, 2026 by GitHub, the CVE Numbering Authority | Published October 23, 2026 by GitHub, the CVE Numbering Authority |
| RustSec ID | RUSTSEC-2026-0380 | RUSTSEC-2026-0379 |
CVE-2026-115889: A Silent Overflow in Cranelift’s Value Tracking
Before Wasmtime 43, Cranelift stored the indices of its SSA values, the intermediate values the compiler tracks inside a function, in 24-bit fields. The advisory explains that these indices could overflow without warning in release builds, so a very large or specially crafted function body could make the compiler point at the wrong value and miscompile the code.
The maintainers warn this can force type confusion or other arbitrary side effects and lead to a sandbox escape on any architecture running the default Cranelift backend. Newer releases were already safe because an earlier change had widened the fields to 32 bits, a change framed as a performance and function-size improvement with no security note. The 36.x LTS line picked it up only in 36.0.19.
CVE-2026-115893: Large br_table Jumps Go Astray on ARM64
The Wasm br_table instruction handles indexed jumps: it picks one of many targets by index and falls back to a default target when the index is out of range. On ARM64, Cranelift reached that default through a conditional branch with a range of about 1 MiB, while the same code sequence also held the full jump table.
Once a single br_table held more than roughly 256,000 targets, the default target fell outside that range and the branch offset wrapped silently. The advisory warns that any aarch64 Wasmtime engine with default settings “can be forced to jump to arbitrary code by a user-controlled Wasm module.” Every version with ARM64 support since 2020 carries the bug, and the fix now sends the default case through the jump table itself.
Affected and Fixed Wasmtime Versions
Exposure depends on the release line and, for the ARM64 flaw, on the host architecture. The ranges below follow the two CVE records.
| Wasmtime Version | CVE-2026-115889 (All Architectures) | CVE-2026-115893 (ARM64) | Upgrade To |
|---|---|---|---|
| Earlier than 36.0.19 (including 24.x) | Affected | Affected | 36.0.19 or a current release |
| 37.0.0 to 42.x | Affected | Affected | 48.0.7, 49.0.4 or 50.0.0 |
| 43.0.0 to 47.x | Not affected | Affected | 48.0.7, 49.0.4 or 50.0.0 |
| 48.0.0 to 48.0.6 | Not affected | Affected | 48.0.7 |
| 49.0.0 to 49.0.3 | Not affected | Affected | 49.0.4 |
| 36.0.19 | Fixed | Fixed | None |
| 48.0.7, 49.0.4, 50.0.0 | Not affected | Fixed | None |
Why 24.x Users Are Left Without a Patch
Under Wasmtime’s release policy, long-term support (LTS) releases receive 24 months of support, and the 24.x line reached that limit in August 2026. Every 24.x version falls inside both vulnerable ranges, so those deployments need a move to 36.0.19 or a newer supported line.
ARM64 Hosts Patched in April Still Need an Update
Some teams upgraded ARM64 hosts to 36.0.7, 42.0.2 or 43.0.1 to fix an earlier Cranelift sandbox escape, CVE-2026-34971. Those builds predate the br_table fix, so they remain exposed to CVE-2026-115893 and need another upgrade.
Multi-Tenant Platforms Face the Most Risk
A Wasmtime sandbox escape requires getting a vulnerable build to compile a module the attacker controls. Both advisories rate the attack as network-reachable with low complexity, low privileges and no user interaction, a profile that fits services where any ordinary account can upload or submit code.
Edge and serverless platforms, plugin systems and other multi-tenant services that run third-party Wasm sit at the top of the list. Applications that compile only their own trusted modules face far less exposure, though the vulnerable compiler stays in place until they update.
What a Wasmtime Sandbox Escape Could Mean for the Host
The advisories describe the direct effect as miscompilation, type confusion or a jump to arbitrary code that breaks the Wasm sandbox. They stop short of describing what an attacker could reach on the host afterward, and no public research has demonstrated a full post-escape chain.
Both CVSS vectors rate confidentiality, integrity and availability impact as high with a changed scope, which means the damage can extend beyond the guest. On a shared host, other tenants’ data or the host process itself could be at risk, depending on how the embedding application isolates its workloads.
No Wasmtime Sandbox Escape Attacks Reported Yet
Neither advisory mentions exploitation, and as of October 26, 2026, no in-the-wild attacks or CISA Known Exploited Vulnerabilities (KEV) listing had been reported for either CVE. Fixed releases went out the same day the advisories were published.
That window may not last. The public fixes and advisories point straight at the affected compiler code, so teams running untrusted Wasm should handle both CVEs as urgent.
Researchers Behind the Reports and PoC Status
The bit-packing flaw came from a researcher credited as jaydns, and the advisory notes the report was submitted with AI assistance. A researcher credited as ilyas-mallah reported the ARM64 flaw.
No public Proof-of-Concept (PoC) had surfaced for either CVE as of October 26, 2026. The advisories describe the trigger conditions, such as a br_table with more than about 256,000 targets, without publishing exploit code.
Finding Wasmtime in Your Stack
Wasmtime usually runs as a library inside another program, so the version of a standalone CLI says little about real exposure. These checks give a fuller picture:
- Resolve Rust Dependencies: Run cargo tree -i wasmtime in each project to see the Wasmtime version actually in use, including through frameworks
- Audit Lockfiles: RustSec tracks the flaws as RUSTSEC-2026-0380 and RUSTSEC-2026-0379, so cargo-audit flags vulnerable Cargo.lock files
- Separate ARM64 Hosts: List hosts running on ARM64, since 43.x to 47.x builds there remain exposed to CVE-2026-115893
- Check Bundled Copies: Review language bindings, runtimes and vendor products that ship Wasmtime, and follow their own advisories
Upgrading Wasmtime and Rebuilding Embedders
Fixed releases close the Wasmtime sandbox escape on every supported line, so the path depends on where each project sits today:
- Move 36.x LTS deployments to 36.0.19
- Move 48.x and 49.x deployments to 48.0.7 or 49.0.4, or jump to 50.0.0, released October 20
- Migrate 24.x and any other unsupported line to a supported release
- Update Cargo.lock, rebuild every embedding application and redeploy it
- Recompile any cached or precompiled modules with the fixed compiler
Start with multi-tenant services that compile outside code. Recompiling cached modules matters because machine code produced by a vulnerable compiler keeps the miscompilation.
Tracking Wasmtime Fixes With SOCRadar
Embedded runtimes are easy to overlook because they sit inside other products and frameworks. SOCRadar helps teams keep track of fixes and threats tied to these flaws:
- Cyber Threat Intelligence: Follow CVE-2026-115889 and CVE-2026-115893 as fixes, exploitation reports, PoC releases and CISA KEV status change.
- Supply Chain Intelligence: Track vendors and platforms that build on Wasmtime as they publish their own advisories.
- Dark Web Monitoring: Get early warning of exploit code or targeting discussions about the Wasmtime sandbox escape in underground channels.
Wasmtime versions inside each environment still require the organization’s own dependency inventory.
Reducing Exposure Before the Upgrade
Neither advisory lists a workaround for the Wasmtime sandbox escape, so the steps below only narrow the window until patched builds are live:
- Restrict Untrusted Modules: Pause or limit compilation of modules from untrusted parties where the business allows it
- Gate Uploads: Require authentication and review for module uploads, and reject unusually large modules or functions
- Harden the Host: Run Wasmtime processes with minimal privileges and strong OS-level isolation, so an escape lands in a constrained environment
Signals Worth Hunting For
The advisories publish no indicators of compromise for the Wasmtime sandbox escape, so the ideas below are hunting hypotheses rather than vendor guidance. Uploaded modules with unusually large functions, or br_table instructions with hundreds of thousands of targets, deserve a closer look.
Crashes or unexpected behavior in Wasmtime host processes, along with outbound connections, file access or child processes from hosts that should only run sandboxed code, are also worth investigating. A clean review does not rule out compromise on hosts that compiled untrusted modules with vulnerable versions.
