Wasmtime sandbox escapes: CVE-2026-115889 and CVE-2026-115893, and the fixed version that depends on your release line

On 19 October 2026 the Bytecode Alliance published two critical advisories for Cranelift, the compiler Wasmtime uses to turn WebAssembly into native code: CVE-2026-115889 and CVE-2026-115893. Both are rated 9.9 under CVSS 3.1, and both end the same way: a module the attacker supplies compiles into machine code that does not respect the sandbox.

This note is for you if you run Wasmtime, or a product that embeds it, and execute modules you did not build yourself. Everything is as of 25 October 2026 and links to its source at the end. Check the advisories before acting on anything time-sensitive.

The short version

• CVE-2026-115889 (GHSA-897f-g5gm-fmxm): Cranelift packs value indices into bit fields, and that can overflow silently in release builds. A very large or crafted function body can cause type confusion and miscompilation. All architectures, default settings.
• CVE-2026-115893 (GHSA-mghf-wjfp-p5xm): on aarch64, a br_table with more than about 256,000 targets compiles to a conditional branch with the wrong target, so execution can jump into other code. aarch64 only.
• Fixed versions: 36.0.19 fixes both on the 36 line. For 115889 the other fix is 43.0.0 or later. For 115893 the fixes are 48.0.7 and 49.0.4. Releases between 37 and 42 have no fix for 115889 listed, so move them to a current release.
• Both need the ability to get a module compiled by your engine. If you only run modules you built and control, your exposure is small.
• Neither advisory lists a workaround. The remedy is to upgrade.

Free PDF · 5 pagesWasmtime sandbox escapes: Assessment & Action PlanThe full version of this note as a PDF for whoever runs your WebAssembly hosts: severity decoded, the fixed version for each release line, exposure by deployment, a per-host procedure, compensating controls with their costs, a hunting checklist and a definition of done.Download the PDF →

Who is actually exposed

Three questions, in order. First, do you run Wasmtime, directly or inside something else such as a serverless platform, a plugin host or a CI sandbox? Second, are you using the default Cranelift compiler? Third, do you compile WebAssembly from a source you do not control: customer code, third-party plugins, user-uploaded modules?

If the answer to the third is no, you are in the low-risk group for both. If it is yes, 115889 applies on every CPU architecture. 115893 applies only if the host is aarch64, which includes Apple Silicon, AWS Graviton and other Arm servers. Do not assume x86_64 clears you: that only rules out 115893.

Three claims in circulation that are wrong

We read the two advisories against several early summaries. These errors recurred, and the first two would send you to a fix that does not exist:

• "Switch to the LLVM backend." We found no such option in the advisories, and they list no workaround at all. Wasmtime's compiler backend is Cranelift. Do not build a mitigation plan around a switch you cannot confirm exists.
• "Fixed in 36.0.19 or 43.0.0", as one version pair for both CVEs. That is true for 115889. For 115893 the advisory lists 36.0.19, 48.0.7 and 49.0.4, and 43.0.0 is not on that list.
• "Both are aarch64 bugs." Only 115893 is. 115889 is architecture-independent.

Step 1 — Find where Wasmtime runs

# Binaries and libraries
wasmtime --version
find / \( -name 'wasmtime*' -o -name 'libwasmtime*' \) -not -path '*/proc/*' 2>/dev/null

# Embedded copies: Rust, Python, Go, container images
grep -rnE 'wasmtime' --include=Cargo.lock --include=Cargo.toml --include='requirements*.txt' --include=go.mod --include=Dockerfile .

# Architecture of each host
uname -m

Also check CI runners, Arm build hosts, and any platform you operate that runs customer or plugin WebAssembly. A binary that links Wasmtime statically will not show up in a package list, so search the lockfiles too.

Step 2 — Upgrade

• 36.x: move to 36.0.19, which fixes both CVEs.
• 37.x to 42.x: no fix for 115889 is listed. Move to 43.0.0 or later, and to 48.0.7 or later if you are on aarch64.
• 43.x to 47.x: not affected by 115889, but affected by 115893 on aarch64. Move to 48.0.7 or later.
• 48.x: 48.0.7. 49.x: 49.0.4.
• Rebuild and redeploy anything that embeds the crate, then verify the version from the running service rather than from the lockfile.
• Add a dependency check that fails builds below the fixed baseline.

If you cannot upgrade this week

There is no vendor workaround, so these reduce exposure rather than remove the bug:

• Stop compiling modules from sources you do not control until the upgrade lands.
• Run the engine in its own low-privilege process, microVM or container with no secrets and no outbound network, so a sandbox escape lands somewhere with nothing to take.
• Reject oversized modules at your loader. This is a heuristic that raises the bar for both bugs, since each needs an unusually large function or branch table. It is not a fix.

What to look for

• Wasm modules with a function body or br_table far larger than anything your users normally submit.
• Engine processes that crash, or that start shells, download tools or open outbound connections.

What we do not know yet

• Whether anyone is exploiting either bug. Neither advisory reports it. Check the CISA Known Exploited Vulnerabilities catalog before relying on that.
• Whether a public proof of concept appears. Both are reported as sandbox escapes, and we have not seen working exploit code.
• Which downstream products bundle an affected Wasmtime, and when they ship fixes.

If you take one thing from this: the version that fixes one of these CVEs is not the version that fixes the other. Look up your release line in each advisory, and do not take a single number from a summary.