Wasmtime: Two CVSS 9.9 Cranelift Sandbox Escapes

What to do

1. Find every Wasmtime copy: cargo tree -i wasmtime in each Rust workspace, plus wasmtime --version for the CLI.
2. Bump the wasmtime crate to 36.0.19, 48.0.7, 49.0.4 or 50.0.0 (cargo update -p wasmtime), then rebuild and redeploy every binary that embeds it.
3. Move off 24.x or any 37-47 line: they are out of support and will not receive these fixes.
4. If you updated ARM64 hosts in April to 36.0.7, 42.0.2 or 43.0.1, update again; those builds are still exposed to CVE-2026-115893.
5. Until patched, stop accepting new untrusted modules on aarch64 hosts, or route them to fixed x86_64 hosts as a stopgap.

How to check if you are affected or compromised

• Check Cargo.lock files for wasmtime and cranelift-codegen versions below the fixed releases; do not rely on Dependabot alone for CVE-2026-115893, which had no reviewed GitHub advisory entry as of Oct 26.
• Review upload logs for unusually large Wasm modules, or modules with huge functions or br_table instructions with hundreds of thousands of targets.
• Look for host processes crashing or misbehaving while compiling or instantiating third-party modules.

What happened#

On October 19, 2026 the Bytecode Alliance published two critical advisories for Wasmtime, the WebAssembly runtime that many Rust programs embed to run sandboxed code. Both bugs are in Cranelift, Wasmtime's default compiler, and both let a crafted Wasm module break out of the sandbox. Each is rated CVSS 3.1 9.9 with a scope change. Fixed releases shipped on October 19 and 20.

• CVE-2026-115889 (GHSA-897f-g5gm-fmxm, all architectures). Before version 43, Cranelift packed internal value numbers into 24-bit fields, and in release builds an overflow wrapped silently. A very large or deliberately crafted function could make the compiler refer to the wrong value. The result is miscompiled code that the advisory says enables "a sandbox escape" with default settings on any platform. Version 43.0.0 (March 2026) fixed this by widening the fields, so the only new release for it is 36.0.19 LTS.
• CVE-2026-115893 (GHSA-mghf-wjfp-p5xm, aarch64 only). On ARM64, out-of-range br_table indexes were sent to the default target through a branch instruction that can only reach about 1 MiB. With a large enough table, the jump lands somewhere else. The advisory states plainly that "any Wasmtime engine running on aarch64 with default settings can be forced to jump to arbitrary code". According to The Hacker News, the bug dates back to Wasmtime's first ARM64 support in 2020. The 50.0.0 release notes list it as "fix br_tables with very large target count".

Who is affected#

Exposure depends on which version line you run:

Wasmtime	CVE-2026-115889	CVE-2026-115893 (aarch64)
Before 36.0.19 (incl. 24.x)	Affected	Affected
37.0.0 – 42.x	Affected	Affected
43.0.0 – 48.0.6	Not affected	Affected
49.0.0 – 49.0.3	Not affected	Affected
36.0.19, 48.0.7, 49.0.4, 50.0.0+	Fixed	Fixed

Wasmtime is a library, so the version that matters is the one compiled into each product. Updating the wasmtime CLI does nothing for an embedded copy. The supported lines are 36 (LTS), 48, 49 and 50. The 24.x LTS line reached end of support on August 20, 2026 and got no fix.

Do you really need to act?#

It depends on who writes the Wasm. Both bugs require the attacker to supply the module that Wasmtime compiles. That makes them critical for the setups Wasm sandboxing exists for: plugin systems, serverless and edge function platforms, and multi-tenant hosts running customer code. In those, a sandbox escape means one tenant's code runs with the host process's privileges. The ARM64 bug is the more serious one, because it needs no unusual settings and ARM64 servers are now common in cloud fleets.

If your application only compiles Wasm you built yourself from trusted sources, an attacker has no way to feed it a malicious module. Update with your next dependency bump. No exploitation has been reported, neither CVE is in CISA KEV, and the advisories list no workaround.

One trap: The Hacker News notes that GitHub's database had a reviewed entry for CVE-2026-115889 but none for CVE-2026-115893 as of October 26. Dependabot may stay silent about the ARM64 flaw, which is the one most deployments still have.

What to do now#

1. Find every copy: cargo tree -i wasmtime in each workspace, grep -A1 'name = "wasmtime"' Cargo.lock across repositories, and wasmtime --version for the CLI.
2. Update: cargo update -p wasmtime to 36.0.19, 48.0.7, 49.0.4 or 50.0.0 (or change the version requirement in Cargo.toml if it pins an older line). Rebuild and redeploy every binary and image.
3. Leave 24.x and anything from 37 to 47: none of those lines will get these fixes.
4. If you patched ARM64 hosts in April to 36.0.7, 42.0.2 or 43.0.1 for an earlier advisory, they are still exposed to CVE-2026-115893. Update them again.
5. For multi-tenant platforms that cannot ship today, pause new third-party uploads on aarch64 hosts, or schedule them onto patched x86_64 capacity.

How to tell if you were hit#

The advisories give no indicators of compromise. A malicious module has to be large or unusual to trigger either bug. Review upload and deployment logs for oversized modules, very large functions, or br_table instructions with hundreds of thousands of targets. Fixed releases now reject tables with more than 65,520 targets, so rejected uploads after patching are worth a look. Also investigate host processes that crashed or behaved oddly while compiling third-party modules.

Timeline#

• Mar 20, 2026 — Wasmtime 43.0.0 widens Cranelift's value fields, fixing the CVE-2026-115889 root cause on current lines.
• Aug 20, 2026 — The 24.x LTS line reaches end of support.
• Oct 19, 2026 — Advisories published; 36.0.19, 48.0.7 and 49.0.4 released.
• Oct 20, 2026 — Wasmtime 50.0.0 released with both fixes.
• Oct 26, 2026 — No exploitation reported; CVE-2026-115893 still lacks a reviewed GitHub advisory entry.

Vulnerability records

• CVE-2026-115889 · Wasmtime is a runtime for WebAssembly. Prior to 36.0.19 and 43.0.0, the Cranelift compiler backend bit-packs SSA value indices in a way that can silently…
• CVE-2026-115893 · Wasmtime is a runtime for WebAssembly. Prior to 36.0.19, 48.0.7, and 49.0.4, the Cranelift compiler backend on aarch64 can compile a Wasm br_table instruction…

Sources

Original sources first: vendor and project advisories, CVE and government records, the discoverers’ write-ups. Every claim above links to one of these. See how the Security Desk works.

Original and primary sources

1. Bytecode Alliance — GHSA-897f-g5gm-fmxm: Bit-packing in Cranelift compiler causes silent overflow and miscompilation github.com
2. Bytecode Alliance — GHSA-mghf-wjfp-p5xm: Cranelift backend on aarch64 can jump to incorrect target on large Wasm br_table instruction github.com
3. Bytecode Alliance — Wasmtime v50.0.0 release notes github.com
4. CVE record — CVE-2026-115889 cve.org
5. CVE record — CVE-2026-115893 cve.org

Coverage and analysis

1. The Hacker News — Two critical Wasmtime flaws could let malicious WebAssembly modules escape sandboxes thehackernews.com