Critical Wasmtime Flaws Expose WebAssembly Sandboxes to Escape Attacks
Two critical vulnerabilities, **CVE-2026-115889** and **CVE-2026-115893**, have been discovered in **Wasmtime**, a WebAssembly runtime. These flaws could allow a malicious WebAssembly module to bypass the intended sandbox, potentially leading to arbitrary code execution. Organizations leveraging **Wasmtime** in their applications, especially those compiling untrusted modules, are urged to update immediately.

Two significant flaws have been identified in **Wasmtime**, a crucial WebAssembly runtime that enables the execution of WebAssembly code outside of web browsers. These vulnerabilities, rated 9.9 out of 10 on the CVSS scale by **Wasmtime** maintainers at the **Bytecode Alliance**, pose a severe risk of sandbox escape.
### The Vulnerabilities
The two critical vulnerabilities are:
* **CVE-2026-115889**: Affects **Wasmtime** across all processor architectures.
* **CVE-2026-115893**: Specifically impacts **ARM64** (also known as aarch64) systems.
Both bugs reside within **Cranelift**, the default compiler used by **Wasmtime** to convert WebAssembly into machine code. An attacker would need to compile a module they control using a vulnerable **Wasmtime** build to exploit these flaws. While no attacks have been reported, the potential for sandbox escape is a significant concern for services that compile modules from external or untrusted sources, such as **Fastly**'s Compute platform.
### Impact and Risk
**Wasmtime**'s sandbox is designed to strictly limit a module's access to its own memory, host functions, and verified jump locations. A successful sandbox escape could allow a malicious module to break these boundaries, potentially accessing or executing arbitrary code on the host system. The advisories do not specify the full extent of what an attacker could access post-escape.
As of October 26, neither flaw was listed in the **U.S. Cybersecurity and Infrastructure Security Agency (CISA)**'s Known Exploited Vulnerabilities catalog.
### Affected Versions and Remediation
The fixes for these vulnerabilities were released on October 19 and 20. The specific affected versions depend on the **Wasmtime** release line and, for **CVE-2026-115893**, the 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 for two years. Only the 36, 48, 49, and 50 release lines are currently supported and received fixes. Users on unsupported lines must migrate to a supported and patched version.
### Mitigation Steps
Organizations are strongly advised to update to the fixed releases: **36.0.19**, **48.0.7**, or **49.0.4**. **Wasmtime 50.0.0**, released on October 20, also includes fixes for both flaws. Since **Wasmtime** can be embedded as a library, simply updating the command-line tool is insufficient; any program incorporating **Wasmtime** must be rebuilt with a patched version.
There are no known workarounds for these vulnerabilities. Until systems are updated, the primary risk lies in any untrusted module that can be supplied to a vulnerable **Wasmtime** instance. These flaws are tracked in **RustSec** as **RUSTSEC-2026-0380** and **RUSTSEC-2026-0379**.
Notably, **GitHub**'s advisory database had a reviewed entry for **CVE-2026-115889** but not for **CVE-2026-115893** as of October 26, meaning **Dependabot** users might not receive alerts for the **ARM64**-specific flaw.
### Technical Details of the Flaws
**CVE-2026-115889** stems from how **Cranelift** managed value tracking numbers. Prior to version 43, these numbers were packed into 24-bit fields. In release builds, an overflow in these fields would occur silently, leading **Cranelift** to refer to incorrect values and generate erroneous machine code. A sufficiently large or specially crafted WebAssembly function could exploit this to induce type confusion and escape the sandbox. The fix involved widening these fields to 32 bits, a change initially aimed at supporting larger functions.
**CVE-2026-115893** involves the `br_table` WebAssembly instruction, which facilitates jumps to multiple code locations based on an index. On **ARM64**, **Cranelift**'s handling of out-of-range indexes for `br_table` used a branch with a limited reach (approximately 1 MiB). If a `br_table` contained more than roughly 256,000 targets, the jump table would exceed this reach, causing the branch to silently point to an incorrect memory location. This vulnerability, present since **Wasmtime** first supported **ARM64** in 2020, could force a vulnerable **Wasmtime** engine to jump to arbitrary code via a user-controlled WebAssembly module. The fix redirects out-of-range indexes through the jump table itself and limits the maximum number of `br_table` targets to 65,520.