Wasmtime patches two critical WebAssembly sandbox escape flaws
Bytecode Alliance has released fixes for two critical vulnerabilities in Wasmtime, the WebAssembly runtime used to execute WebAssembly code outside browsers. Both flaws, tracked as CVE-2026-115889 and CVE-2026-115893, received a CVSS score of 9.9 and could allow a malicious WebAssembly module to escape the sandbox designed to confine it.
CVE-2026-115889 affects Wasmtime on every processor architecture. CVE-2026-115893 affects ARM64, also known as aarch64. The maintainers published advisories on October 19, with fixed releases issued on October 19 and 20. No attacks had been reported as of October 26.
Risk is concentrated around untrusted modules
Wasmtime embeds WebAssembly in host software and relies on a sandbox to limit a module to its own memory, approved host functions and checked control-flow locations. Exploitation of either issue requires an attacker to supply a module that they control. That makes services which compile third-party WebAssembly a particularly important exposure point.
The advisories do not identify affected services or specify what an attacker could reach after a successful sandbox escape. Fastly has stated that its Compute platform runs customer code with Wasmtime, illustrating the type of deployment where externally supplied modules require close attention.
Neither vulnerability was listed in CISA’s Known Exploited Vulnerabilities catalog as of October 26. Both are recorded in RustSec as RUSTSEC-2026-0380 and RUSTSEC-2026-0379. GitHub had a reviewed advisory for CVE-2026-115889 but not for the ARM64 issue; because Dependabot alerts are triggered only by reviewed entries, users should not rely on an alert for CVE-2026-115893.
Different defects, different release impact
Both vulnerabilities originate in Cranelift, Wasmtime’s default compiler for translating WebAssembly into machine code. CVE-2026-115889 stems from value-tracking fields that were 24 bits wide before Wasmtime 43. In release builds, values that exceeded the field size could overflow without an error, causing Cranelift to refer to an incorrect value and generate incorrect machine code.
A sufficiently large or deliberately constructed function can use that condition to force type confusion and escape the sandbox. The main development line had widened the fields to 32 bits in a change merged on February 18 and released in Wasmtime 43.0.0 on March 20. The 36.x LTS line received the corresponding change on October 19.
CVE-2026-115893 concerns the WebAssembly br_table instruction on ARM64. For indexes outside a branch table, Cranelift used a branch to a default target. That branch has a reach of roughly 1 MiB, so a table with more than about 256,000 targets could cause the branch to point to the wrong location. The advisory states that a user-controlled module could force an ARM64 engine using default settings to jump to arbitrary code.
The ARM64 issue has existed since Wasmtime added ARM64 support in 2020. Its fix routes out-of-range indexes through the jump table, avoiding the long branch, and fixed releases reject a br_table with more than 65,520 targets.
Update embedded runtimes, not only command-line tools
Organizations should move to Wasmtime 36.0.19, 48.0.7, 49.0.4 or 50.0.0. Release lines 37 through 42 are affected by both flaws but are unsupported, while releases 43 through 47 are unaffected by CVE-2026-115889 but remain exposed to the ARM64 issue. Wasmtime 50.0.0, released October 20, fixes both vulnerabilities.
Wasmtime can be included as a library, so updating its command-line utility does not secure programs that embed the runtime. Each affected application must be rebuilt with a fixed Wasmtime version. Teams should inventory software that accepts externally supplied WebAssembly, identify ARM64 deployments, and prioritize rebuilding those hosts with a supported fixed release.