Critical Wasmtime sandbox escapes fixed in latest releases

Maintainers of the Wasmtime WebAssembly runtime released urgent security patches on October 19 and 20, 2026, to address two critical vulnerabilities. These flaws, rated 9.9 out of 10 on the CVSS scale, could allow a malicious module to break out of its sandbox and execute arbitrary code on the host system.

What happened

The Bytecode Alliance, which maintains Wasmtime, identified two separate bugs in Cranelift, the default compiler used to translate WebAssembly into machine code. The first vulnerability, tracked as CVE-2026-115889, affects Wasmtime installations across all processor architectures. The second, CVE-2026-115893, is specific to ARM64 (aarch64) systems. Both issues permit a sandbox escape if an attacker can supply a crafted WebAssembly module to a vulnerable runtime.

The risk is most acute for platforms that compile and run user-supplied code, such as serverless compute environments. For instance, services like Fastly’s Compute platform rely on Wasmtime to isolate customer code. While the advisories do not name specific victims or detail post-exploitation access, the potential for full host compromise is severe. As of October 26, no active exploits have been reported, and neither flaw appears in the CISA Known Exploited Vulnerabilities catalog.

Support status plays a major role in exposure. Only the 36, 48, 49, and 50 release lines currently receive security updates. Older lines, including the 24.x LTS branch which ended support on August 20, 2026, will not receive fixes. Users on unsupported versions must upgrade to a supported line to mitigate these risks.

How it works

CVE-2026-115889 stems from an integer overflow in how Cranelift tracks values within a function. In versions prior to 43.0.0, the compiler stored these tracking numbers in 24-bit fields. If a function was large or complex enough to exceed this limit, the value would overflow silently in release builds. This caused Cranelift to reference incorrect values, leading to type confusion and generated machine code that violated sandbox constraints. The fix widens these fields to 32 bits, a change originally merged in February for performance reasons but backported to the 36.x LTS line on October 19 for security.

The ARM64-specific flaw, CVE-2026-115893, involves the br_table instruction, which handles multi-way branches. When an index falls outside the table range, the runtime jumps to a default target. On ARM64, Cranelift implemented this using a branch instruction with a limited reach of about 1 MiB. If a br_table contained more than roughly 256,000 targets, the jump table exceeded this range, causing the branch to point to an unintended memory location. This allowed a crafted module to redirect execution to arbitrary code. The patch modifies the control flow to route out-of-range indexes through the jump table itself and caps br_table size at 65,520 targets.

Key details

• CVE-2026-115889 affects all architectures; CVE-2026-115893 affects only ARM64 systems.
• Both vulnerabilities carry a CVSS score of 9.9, indicating critical severity.
• Fixed versions include 36.0.19, 48.0.7, 49.0.4, and 50.0.0.
• The 24.x LTS line is unsupported and received no patch; users must migrate.
• Dependabot may not alert for the ARM64 flaw as GitHub lacks a reviewed entry for it.
• Spin framework version 4.2.4 updated to Wasmtime 50.0.0 on October 21.

Why it matters

For engineers building platforms that execute untrusted WebAssembly, these bugs represent a fundamental failure of isolation. Sandboxing is the primary defense mechanism in such architectures. If a module can escape, it gains the privileges of the host process, potentially allowing data exfiltration, lateral movement, or service disruption. The fact that one bug existed since 2020 highlights the difficulty of auditing low-level compiler logic, especially for architecture-specific edge cases.

Additionally, the reliance on automated tools like Dependabot may provide a false sense of security. Because GitHub requires reviewed entries to trigger alerts, and the ARM64 flaw lacked one as of late October, some teams might remain unaware of their exposure. This underscores the need for manual verification of dependency trees against official vendor advisories, particularly for critical infrastructure components like runtimes.

What you can do

• Identify your current Wasmtime version and check if it falls within the affected ranges listed in the advisory.
• Upgrade to 36.0.19, 48.0.7, 49.0.4, or 50.0.0 depending on your release line.
• If you use Wasmtime as a library, rebuild your application with the patched version; updating the CLI tool is insufficient.
• Migrate away from unsupported release lines like 24.x, as they will not receive future security fixes.
• Run cargo-audit to check for RUSTSEC-2026-0380 and RUSTSEC-2026-0379 in your dependency lock files.
• Monitor for updates from downstream frameworks like Spin if you do not manage Wasmtime directly.