Two critical vulnerabilities in Wasmtime, a widely-used WebAssembly runtime, could allow attackers to break out of the security sandbox designed to isolate malicious code, according to advisories published by the project's maintainers on October 19. Both flaws reside in Cranelift, the default compiler Wasmtime uses to convert WebAssembly into machine code, and each received a severity rating of 9.9 out of 10 on the CVSS scale. The maintainers released patched versions on October 19 and 20, and no active exploitation has been reported.
The first vulnerability, CVE-2026-115889, affects Wasmtime across all processor types, while the second, CVE-2026-115893, impacts only ARM64 systems, also known as aarch64. Versions before 36.0.19 are vulnerable to both flaws, and releases from 37.0.0 through 42.x remain exposed to both issues. Versions 43.0.0 through 47.x, as well as 48.0.0 through 48.0.6 and 49.0.0 through 49.0.3, are affected only by the ARM64 flaw. Fixed releases include 36.0.19, 48.0.7, 49.0.4, and 50.0.0 or later. Wasmtime provides long-term support for releases numbered in multiples of 12 for two years, while other releases receive support for just two months. Only the 36, 48, 49, and 50 release lines currently have support, meaning older versions, including the 24.x LTS line whose support ended August 20, 2026, received no patches. ARM64 systems that updated to 36.0.7, 42.0.2, or 43.0.1 in April to address an earlier Cranelift sandbox escape remain vulnerable to CVE-2026-115893.
The maintainers at the Bytecode Alliance warn that both bugs require an attacker to first get a vulnerable Wasmtime build to compile a module under their control, making the risk highest for services that compile modules written by outside users. Fastly, for instance, states its Compute platform executes customer code using Wasmtime. The sandbox is intended to confine a module to strict boundaries: it can only access its own memory and the host functions provided to it, and its code can only jump to verified locations. Neither flaw appeared in the Known Exploited Vulnerabilities catalog maintained by the U.S. Cybersecurity and Infrastructure Security Agency (CISA) as of October 26. The advisories don't identify which services are affected or specify what resources an attacker could reach after breaking out of the sandbox.
CVE-2026-115889 stems 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 would overflow silently. Cranelift could then reference the wrong value, generating faulty machine code. A very large WebAssembly function, or one deliberately crafted to use many values, can exploit this to force type confusion and escape the sandbox, the advisory explains. Wasmtime's main development line had already eliminated the problem with a change merged February 18 that widened the fields to 32 bits, shipping in version 43.0.0 on March 20. The change was originally described as a way to compile larger functions, with no mention of security implications. CVE-2026-115893 involves br_table, a WebAssembly instruction that jumps to one of many code locations based on an index, with out-of-range indexes sent 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 roughly 256,000 targets made the jump table too large for that reach, causing the branch to silently point 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 states. This bug has existed since Wasmtime first supported ARM64 in 2020.
Hosts need to update to the fixed release for their line: 36.0.19, 48.0.7, or 49.0.4, while Wasmtime 50.0.0, released October 20, contains fixes for both flaws. Because Wasmtime can be embedded into other programs as a library, updating the command-line tool alone won't protect them—each program that includes Wasmtime must be rebuilt with a patched version. Neither advisory provides a workaround, meaning the risk persists from any module an outsider can supply until the host is updated. Both flaws are listed in RustSec as RUSTSEC-2026-0380 and RUSTSEC-2026-0379, and as of October 26, GitHub's advisory database had a reviewed entry for CVE-2026-115889 but none for CVE-2026-115893. 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. Organizations running WebAssembly workloads need to audit their entire stack, not just user-facing tools, since the real exposure lies in whatever software invisibly depends on Wasmtime as a library. Services that invite untrusted code face a window of vulnerability that shrinks only as fast as their rebuild and deployment pipelines allow.