Wasmtime fixes two critical Cranelift sandbox escapes, CVE-2026-115889 and CVE-2026-115893

Timing note: the Bytecode Alliance published both advisories and the fixed releases on 19 October 2026, a week before this article. This is not a new disclosure. We cover it now because the flaws are critical and many apps embed Wasmtime.

What happened

On 19 October 2026, the Wasmtime maintainers at the Bytecode Alliance published two critical advisories. Both flaws sit in Cranelift, the compiler Wasmtime uses by default to turn WebAssembly (Wasm) into machine code. In both cases, a crafted Wasm module can make Cranelift produce wrong machine code and escape the sandbox.

CVE-2026-115889 affects every architecture. Before Wasmtime 43, Cranelift packed its internal value numbers into fields that can silently overflow in release builds. A very large or crafted function can then trigger type confusion, the advisory says.

CVE-2026-115893 affects ARM64 (aarch64) only. A br_table instruction, a jump to one of many targets, with more than about 256,000 targets can leave one branch pointing to the wrong code. The module controls the offset of that jump.

The vendor rates each flaw CVSS 3.1 9.9 (Critical). Fixed releases 36.0.19, 48.0.7 and 49.0.4 came out the same day, and 50.0.0 followed on 20 October.

Who is affected

Wasmtime runs WebAssembly outside the browser. It is often built into other software as a library: apps with plugin systems, edge and serverless platforms, and services that run code written by someone else. A sandbox escape means a module that should only touch its own memory and the functions the host gives it can break out of those limits. The advisories do not say what an attacker could reach after that.

The risk is highest where the host compiles Wasm modules it does not trust. Both advisories describe the attack as coming from a crafted or user-controlled module. If you only run modules you build yourself, an outsider has no direct way in, but you still need the update.

Affected versions for CVE-2026-115889: before 36.0.19, and 37.0.0 to 42.x. Wasmtime 43.0.0 and later, including the 48.x and 49.x lines, are not affected by this one.

Affected versions for CVE-2026-115893, on aarch64 only: before 36.0.19, 37.0.0 up to 48.0.7, and 49.0.0 up to 49.0.4. The advisory says every version with aarch64 support is affected, since that support first shipped in 2020, before Wasmtime 1.0.

What is confirmed

Both advisories were published on 19 October 2026 and list the wasmtime Rust crate as the affected package. Both apply to engines with default settings, which use the Cranelift backend. NVD published both entries on 23 October 2026, with the vendor's 9.9 score only and no NVD score of its own.

CVE-2026-115889 was already fixed on the main line before it was flagged as a security bug. Pull request 12613, merged on 18 February 2026, widened the fields to full 32-bit values with limit checks, and shipped in Wasmtime 43.0.0 on 20 March 2026. The 36.x line received the same fix in 36.0.19.

CVE-2026-115893 is fixed in 36.0.19, 48.0.7 and 49.0.4, and the 50.0.0 release notes list the fix too. The advisories credit GitHub users jaydns (CVE-2026-115889) and ilyas-mallah (CVE-2026-115893) as reporters.

Neither CVE is in the CISA KEV catalog (catalog version 2026.10.23, checked on 26 October 2026). Both are listed in RustSec, the database that cargo-audit checks.

What is not confirmed

ThreatWire found no report of exploitation and no public proof of concept for either flaw. The maintainers have not reported any attacks. That can change, so check the advisories again before you close the ticket.

The advisories do not say what an attacker can do on the host after escaping the sandbox. They also do not say when the security impact of CVE-2026-115889 was recognized, or name the exact first release that added aarch64 support.

Neither advisory lists a workaround. They do not say whether Wasmtime's other execution backends avoid the flaws, or whether modules precompiled with an affected version must be compiled again. Treat both points as open until the maintainers say otherwise.

What to do

Update to a fixed release for your line: 36.0.19, 48.0.7 or 49.0.4, or move to 50.0.0. If you are on any other line, such as 37 to 47, move to one of these releases.

Updating the wasmtime command-line tool is not enough for apps that embed Wasmtime. The fix lives in the wasmtime crate, so each app, plugin host or platform that links it must bump the dependency, rebuild and ship a new build. Run cargo-audit on your Cargo.lock to find old copies, including ones pulled in through other crates.

Until you are patched, treat every Wasm module an outsider can supply as a risk, and prioritize ARM64 hosts, which are exposed to both flaws. If you run a hosted service on Wasmtime, ask your provider whether it has updated.

Sources: Bytecode Alliance Wasmtime advisories GHSA-897f-g5gm-fmxm and GHSA-mghf-wjfp-p5xm, Wasmtime release notes for 36.0.19, 43.0.0, 48.0.7, 49.0.4 and 50.0.0, Wasmtime pull request 12613, NVD, CVE.org, RustSec and the CISA KEV catalog.