Critical Wasmtime flaws require rebuilding embedded runtimes
Wasmtime maintainers have disclosed two critical flaws in the WebAssembly runtime that could let a malicious module escape its sandbox. Fixed releases were issued on October 19 and 20, but the practical impact depends on the release line, processor architecture and whether Wasmtime is embedded in another application. No attacks exploiting either flaw had been reported in the supplied advisory material.
The vulnerabilities are in Cranelift, Wasmtime’s default compiler for turning WebAssembly into machine code. CVE-2026-115889 affects all processor architectures and can arise when a very large or specially constructed WebAssembly function causes incorrect machine code. CVE-2026-115893 is limited to ARM64, also known as aarch64, and involves an oversized br_table jump table. In the affected configuration, a user-controlled module can force an arbitrary-code jump.
The risk is most relevant to services that compile WebAssembly supplied by outside users. Wasmtime’s sandbox is intended to restrict a module to its own memory, approved host functions and checked code locations; escaping it undermines those boundaries. The available advisories do not specify what an attacker could access after an escape, so the downstream impact must be assessed from the host application’s permissions rather than assumed.
Administrators should first identify the Wasmtime release line and host architecture. The supported lines are 36, 48, 49 and 50. The listed fixed targets are 36.0.19, 48.0.7 and 49.0.4; Wasmtime 50.0.0 is fixed for both vulnerabilities. Hosts on an unsupported line need to move to one of those releases, because the former 24.x long-term-support line received no fix after support ended.
ARM64 operators need particular care. Systems that previously moved to Wasmtime 36.0.7, 42.0.2 or 43.0.1 for an earlier ARM64 Cranelift sandbox escape can still be affected by CVE-2026-115893. Updating only to one of those earlier versions is therefore not sufficient for this issue.
Updating the Wasmtime command-line tool is not enough when the runtime is compiled into another product. Each application that includes Wasmtime must be rebuilt with a fixed version. Teams using Rust dependency auditing can also check for the corresponding RustSec entries, RUSTSEC-2026-0380 and RUSTSEC-2026-0379.
There is no workaround listed in either advisory. Until affected hosts are updated, the stated exposure comes from any WebAssembly module an outsider can supply. Neither vulnerability was in CISA’s Known Exploited Vulnerabilities catalog as of October 26, and the maintainers had not reported attacks, but those points do not replace version and dependency checks for systems accepting untrusted modules.