Two Wasmtime flaws require embedded apps to be rebuilt
Two critical Wasmtime flaws could allow an attacker-controlled WebAssembly module to escape the restrictions meant to contain it. Wasmtime is a runtime, software that executes WebAssembly code outside a web browser, and it can also be embedded as a library inside other applications. The Bytecode Alliance, which maintains the project, assigned both vulnerabilities a score of 9.9 out of 10 under the Common Vulnerability Scoring System (CVSS), a standard measure of security severity. Fixed releases arrived on October 19 and 20, and the maintainers have not reported any attacks.
The vulnerabilities are in Cranelift, Wasmtime's default compiler for converting WebAssembly modules into instructions a processor can execute. CVE-2026-115889 affects Wasmtime on every processor architecture, while CVE-2026-115893 is limited to ARM64, also known as aarch64. Exploitation requires a vulnerable Wasmtime build to compile a module controlled by the attacker. This makes services that accept and compile other people's modules the highest-risk environments. Fastly, for example, says its Compute platform uses Wasmtime to run customer code, although the advisories do not identify affected services or say what an attacker could reach after an escape.
A Wasmtime sandbox is intended to restrict a module to its assigned memory and the host functions, or approved capabilities, supplied by the application. It also limits code execution to checked destinations. The two flaws undermine those boundaries during compilation. Neither vulnerability appeared in the Known Exploited Vulnerabilities catalog maintained by the U.S. Cybersecurity and Infrastructure Security Agency (CISA) as of October 26.
The affected releases differ between the two flaws. Versions before 36.0.19, including the 24.x line, are vulnerable to both issues on ARM64 and to CVE-2026-115889 on other architectures. Version 36.0.19 fixes both. Releases from 37.0.0 through 42.x are affected by both vulnerabilities where ARM64 applies. Releases from 43.0.0 through 47.x are not affected by CVE-2026-115889, but remain vulnerable to the ARM64-specific flaw. Versions 48.0.0 through 48.0.6 and 49.0.0 through 49.0.3 are also affected by CVE-2026-115893. The fixed releases are 36.0.19, 48.0.7, 49.0.4 and 50.0.0 or later.
Wasmtime designates releases numbered in multiples of 12 as long-term support (LTS) versions and supports them for two years. Other releases receive two months of support, with security fixes guaranteed only for supported lines. At the time of the advisories, only the 36, 48, 49 and 50 lines remained supported. Other lines received no fix, including the 24.x LTS branch, whose support ended on August 20, 2026. ARM64 systems updated in April to 36.0.7, 42.0.2 or 43.0.1 for an earlier Cranelift escape are still vulnerable to CVE-2026-115893.
Administrators should move to 36.0.19, 48.0.7, 49.0.4 or 50.0.0, depending on the release line. Unsupported installations must migrate to one of those fixed branches. Updating only the Wasmtime command-line program is not enough when an application contains Wasmtime as a library. Every affected application must be rebuilt using a corrected version. Neither advisory provides a workaround, so any module supplied by an outside party remains a potential source of risk until the relevant host software is updated and rebuilt.
CVE-2026-115889 resulted from the way older Cranelift versions recorded identifiers used to track values within a function. Before version 43, these identifiers occupied 24-bit fields. In release builds, an identifier too large for that field could overflow without producing an error. Cranelift could consequently reference the wrong value and generate incorrect machine code. According to the advisory, a very large WebAssembly function, or one deliberately constructed to create many values, could trigger type confusion and escape the sandbox.
The main Wasmtime development line had already removed that condition before its security implications were documented. A change merged on February 18 expanded the affected fields to 32 bits and shipped in Wasmtime 43.0.0 on March 20. The change was described at the time as support for compiling larger functions, without mentioning security. The 36.x LTS branch received the same change on October 19. The advisory does not state when maintainers recognised the security impact.
CVE-2026-115893 concerns br_table, a WebAssembly instruction that selects one of many code destinations from an index and uses a default destination when the index falls outside the table. On ARM64, Cranelift handled an out-of-range index with a branch that could reach only about 1 MiB. A br_table containing more than about 256,000 destinations could become too large for that reach, causing the branch to point silently to the wrong location. The maintainers say a user-controlled module could use this condition to make a default Wasmtime engine on ARM64 jump to arbitrary code. The flaw had existed since ARM64 support was introduced in 2020. The correction routes out-of-range indexes through the jump table itself and rejects a br_table with more than 65,520 destinations.
Both vulnerabilities are recorded in RustSec, the security database used by cargo-audit to examine Cargo.lock dependency files, as RUSTSEC-2026-0380 and RUSTSEC-2026-0379. As of October 26, GitHub's advisory database had reviewed CVE-2026-115889 but did not have a reviewed entry for CVE-2026-115893. Because GitHub says Dependabot alerts require a reviewed entry, users should not expect it to notify them about the ARM64 flaw at that point. Spin, an open-source tool for serverless WebAssembly applications, adopted Wasmtime 50.0.0 in version 4.2.4 on October 21.
Website and cloud application operators should therefore check both direct Wasmtime installations and software that embeds the runtime, paying particular attention to ARM64 hosts and unsupported release lines. For organisations that need help reviewing their technology environment, AEU-I provides security-first IT, infrastructure and consulting. The essential remediation remains installing a fixed Wasmtime release and rebuilding every application that includes the vulnerable library.