Two critical flaws in Wasmtime, a WebAssembly runtime that can be built into other software, could allow a malicious WebAssembly module to escape the sandbox intended to contain it, the project’s maintainers say.
An attacker would first need a vulnerable Wasmtime build to compile a module they control, and one of the flaws affects only ARM64 systems. Fixed versions were released on October 19 and 20, and the maintainers have not reported any attacks.
Wasmtime runs WebAssembly code outside web browsers. Both bugs are in Cranelift, the compiler it uses by default to turn WebAssembly into machine code. Wasmtime’s maintainers at the Bytecode Alliance rated each flaw 9.9 out of 10 on the CVSS scale in advisories published on October 19.
The sandbox is meant to keep a module inside set limits. A module can only use its own memory and the host functions it is given, and its code can only jump to checked locations.
Because both flaws need a module the attacker controls, the risk is highest for services that compile modules written by other people. Fastly, for example, says its Compute platform runs customer code using Wasmtime. The advisories do not name any affected services or specify what an attacker could access after escaping the sandbox.
Neither flaw was in the Known Exploited Vulnerabilities catalog kept by the U.S. Cybersecurity and Infrastructure Security Agency (CISA) as of October 26.
Which Versions Are Affected
The two flaws were fixed at different times, so whether your version is affected depends on your release line and, for one flaw, your processor architecture.
| Wasmtime version | CVE-2026-115889 (any architecture) | CVE-2026-115893 (ARM64 only) | What to do |
|---|---|---|---|
| Before 36.0.19 (includes 24.x) | Affected | Affected | Update to 36.0.19, or move to 48.0.7, 49.0.4 or 50.0.0 |
| 36.0.19 | Fixed | Fixed | None needed for these flaws |
| 37.0.0 through 42.x | Affected | Affected | Move to 48.0.7, 49.0.4 or 50.0.0 |
| 43.0.0 through 47.x | Not affected | Affected | Move to 48.0.7, 49.0.4 or 50.0.0 |
| 48.0.0 through 48.0.6 | Not affected | Affected | Update to 48.0.7 |
| 48.0.7 | Not affected | Fixed | None needed for these flaws |
| 49.0.0 through 49.0.3 | Not affected | Affected | Update to 49.0.4 |
| 49.0.4, and 50.0.0 or later | Not affected | Fixed | None needed for these flaws |
Wasmtime supports long-term support (LTS) releases, which are numbered in multiples of 12, for two years. Other releases get two months. Security fixes are guaranteed for supported releases.
Only the 36, 48, 49, and 50 release lines are still supported. Every other line, including the 24.x LTS line whose support ended on August 20, 2026, got no fix.
ARM64 hosts that updated to 36.0.7, 42.0.2, or 43.0.1 in April to fix an earlier Cranelift sandbox escape on ARM64 are still affected by CVE-2026-115893.
What to Do
Update to the fixed release for your line: 36.0.19, 48.0.7, or 49.0.4. Wasmtime 50.0.0, released on October 20, is fixed for both flaws. Hosts on an unsupported line need to move to one of these releases.
Wasmtime can be built into other programs as a library, so updating the command-line tool does not fix them. Each program that includes Wasmtime needs to be rebuilt with a fixed version.
Neither advisory lists a workaround. Until a host is updated, the risk comes from any module an outsider can supply.
Both flaws are listed in RustSec, the database the cargo-audit tool uses to check Cargo.lock files, as RUSTSEC-2026-0380 and RUSTSEC-2026-0379.
As of October 26, GitHub’s advisory database had a reviewed entry for CVE-2026-115889 but none for CVE-2026-115893. GitHub says only reviewed entries trigger Dependabot alerts, so Dependabot users should not expect an alert for the ARM64 flaw.
Spin, an open-source tool for building serverless WebAssembly apps that runs on Wasmtime, moved to Wasmtime 50.0.0 in version 4.2.4 on October 21.
How the Two Flaws Work
CVE-2026-115889 comes from how Cranelift stored the numbers it uses to track values inside a function. Before version 43, it packed these numbers into 24-bit fields, and in release builds, a number too large for its field overflowed without any error.
Cranelift could then refer to the wrong value, producing incorrect machine code. A very large WebAssembly function, or one crafted to use many values, can use this to force type confusion and escape the sandbox, according to the advisory.
Wasmtime’s main development line had already removed the problem. A change merged on February 18 widened the fields to 32 bits and shipped in Wasmtime 43.0.0 on March 20. Its description presented it as a way to compile larger functions and did not mention security.
The 36.x LTS line got the same change on October 19. The advisory does not say when the security impact was recognized.
CVE-2026-115893 involves br_table, a WebAssembly instruction that jumps to one of many places in the code based on an index. An index outside the table goes to a default target. On ARM64, Cranelift sent these out-of-range indexes to the default with a branch that can only reach about 1 MiB.
A br_table with more than about 256,000 targets made the jump table too big for that reach, so the branch silently pointed to the wrong place.
Any Wasmtime engine on ARM64 with default settings “can be forced to jump to arbitrary code by a user-controlled Wasm module,” the advisory says. The bug has been present since Wasmtime first supported ARM64 in 2020.
The fix sends out-of-range indexes through the jump table itself, so no long branch is needed. Fixed versions also refuse to compile a br_table with more than 65,520 targets.
