Two Critical Wasmtime Flaws Could Let Malicious WebAssembly Modules Escape Sandboxes

Two critical flaws in Wasmtime, a WebAssembly runtime that can be built into other software, could let a malicious WebAssembly module escape its sandbox, according to the project's maintainers. An attacker would first need a vulnerable build to compile a module they control, and one flaw affects only ARM64 systems. Fixed versions were released on October 19 and 20, and the maintainers have not reported any attacks.

What is affected

Both bugs are in Cranelift, the compiler Wasmtime uses by default. CVE-2026-115889 affects all processor architectures, while CVE-2026-115893 affects only ARM64, also called aarch64. The Bytecode Alliance rated each flaw 9.9 out of 10 on the CVSS scale. Risk is highest for services that compile modules written by other people; Fastly says its Compute platform runs customer code using Wasmtime. The advisories do not name affected services or specify what an attacker could access after escaping. Neither flaw was in CISA's Known Exploited Vulnerabilities catalog as of October 26.

Version fixes

Fixed releases are 36.0.19, 48.0.7, 49.0.4, and 50.0.0. Builds before 36.0.19, versions 37.0.0 through 42.x, versions 43.0.0 through 47.x, 48.0.0 through 48.0.6, and 49.0.0 through 49.0.3 on ARM64 need updates. Hosts on unsupported lines must move to a supported release. Only the 36, 48, 49, and 50 release lines are still supported; support for the 24.x LTS line ended on August 20, 2026, and it received no fix. ARM64 hosts that updated in April to fix an earlier Cranelift sandbox escape are still affected by CVE-2026-115893.

How the flaws work

CVE-2026-115889 comes from Cranelift storing value tracking numbers in 24 bit fields before version 43. In release builds, a number too large for its field overflowed without error, so Cranelift could refer to the wrong value and produce incorrect machine code. A very large or crafted WebAssembly function can use this to force type confusion and escape the sandbox. Wasmtime's main development line widened the fields to 32 bits in version 43.0.0 on March 20, and the 36.x LTS line got the same change on October 19. CVE-2026-115893 involves br_table on ARM64. Out of range indexes were sent to the default target with a branch that can reach about 1 MiB, so a br_table with more than about 256,000 targets made the jump table too big and the branch silently pointed to the wrong place. The bug has been present since Wasmtime first supported ARM64 in 2020. The fix sends out of range indexes through the jump table and refuses to compile a br_table with more than 65,520 targets.

Other details

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. Both flaws are listed in RustSec 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, and GitHub says only reviewed entries trigger Dependabot alerts. Spin moved to Wasmtime 50.0.0 in version 4.2.4 on October 21.

Sources: The Hacker News