wasmtime, a popular WebAssembly runtime used to embed wasm execution in serverless platforms, developer tools, and CDN-like services, has been found vulnerable to two severe security flaws. Both bugs allow a WebAssembly module — if supplied by an attacker — to escape its sandbox and gain unintended access to system resources. The maintainers issued fixes on October 19 and 20, 2026, and say there is no evidence yet of these flaws being exploited. The severity for both has been rated 9.9/10 on the CVSS scale.
Which Wasmtime Versions Are at Risk
The first flaw, tagged CVE-2026-115889, affects all architectures. The second, CVE-2026-115893, is limited to ARM64 (aarch64) hosts. If you’re running wasmtime older than version 36.0.19, you’re exposed to both bugs. Versions 37.0.0 through 42.x are also at risk on all platforms; versions 43.0.0 through 47.x are safe from the first flaw but still vulnerable to the ARM-only issue. The newer releases — 48.0.7, 49.0.4 and the freshly shipped 50.0.0 — contain fixes for both vulnerabilities.
Note that only release lines 36, 48, 49, and 50 are still supported; older LTS lines, including 24.x whose support ended in August 2026, no longer receive updates.
Root Cause and Technical Details
Both bugs reside in Cranelift, the default compiler within wasmtime that converts wasm bytecode into machine instructions. CVE-2026-115889 involves how Cranelift stored internal value identifiers inside functions. In builds prior to version 43, it used 24-bit fields, which overflowed silently when a function had too many values, leading to wrong references and miscompiled code. The change to 32-bit fields was made in version 43 and back-ported to line 36 on October 19.
CVE-2026-115893 relates to the br_table instruction, used to jump among multiple possible targets depending on an index. On ARM64, if indexes are out of range, Cranelift was using a default branch that could reach only a limited distance (about 1 MiB). With tables of over ~256,000 entries, that branch couldn’t reach the default target, resulting in jumps to unintended code — effectively enabling attacker control. The fix changes out-of-range behavior to route through the jump table itself, and compilers reject tables larger than 65,520 entries.
What You Should Do
Upgrade to a safe version immediately: 36.0.19, 48.0.7, 49.0.4, or 50.0.0 or higher. If you’re using an unsupported release line, moving to a supported one with a fix is crucial. Since wasmtime can be embedded as a library, updating just the standalone binary isn’t enough — every application that builds in wasmtime must be recompiled with a patched version to be secure.
Until upgrades are in place, services that accept wasm modules from third parties (serverless platforms, compute-on-edge providers, etc.) are most at risk. Neither bug has mitigations or workarounds beyond updating.
Both vulnerabilities are now tracked in RustSec, which cargo-audit uses to scan dependency files. The broader GitHub advisory database has reviewed the first issue, but the ARM64-only flaw hasn’t yet been fully reviewed, meaning some alerts (like Dependabot’s) may not catch it in certain setups.
Why This Matters: Wasmtime’s sandbox model is intended to isolate untrusted WebAssembly code — only allowing access to memory, exports, and host functions you explicitly allow. But these bugs create avenues for modules to step outside those restrictions.
These issues highlight how complexity in compilers and runtimes, especially corner cases like large jump tables or many internal values, can undermine security guarantees. The broader lesson: whenever you integrate third-party code execution services, early patching and dependency tracking tools are vital.
