“Wasmtime's maintainers at the Bytecode Alliance rated each flaw 9.9 out of 10 on the CVSS scale in advisories published on October 19.”
CVE-2026-115889: 24‑bit packing overflow that can make the compiler misrefer
The first vulnerability, CVE-2026-115889, stems from how Cranelift — Wasmtime’s default compiler — stored the internal numbers it uses to track values inside a function. Before the change merged into the main line on February 18 and shipped in Wasmtime 43.0.0 on March 20, Cranelift packed those numbers into 24‑bit fields. In release builds a value too large for a 24‑bit field could overflow without producing an error, allowing Cranelift to refer to the wrong value and produce incorrect machine code.
According to the advisory, a very large WebAssembly function or one crafted to use many values can exploit this condition to force type confusion and escape the sandbox that is meant to confine WebAssembly modules. The 36.x long‑term support (LTS) branch received the same fix on October 19; the advisory does not state when the security implications were first recognized.
CVE-2026-115893: ARM64 br_table reach limits let out‑of‑range indexes land wrong
The second flaw, CVE-2026-115893, is specific to ARM64 (aarch64) hosts and involves the WebAssembly br_table instruction, which jumps to one of many code targets based on an index. When an index is out of range, br_table is supposed to go to a default target. On ARM64, Cranelift implemented that default branch using a long branch that can reach only about 1 MiB.
When a br_table contained more than roughly 256,000 targets, the jump table exceeded what the long branch could reach; the branch then silently pointed to the wrong place. The advisory states plainly that any Wasmtime engine on ARM64 with default settings "can be forced to jump to arbitrary code by a user-controlled Wasm module." The bug dates back to Wasmtime’s first ARM64 support in 2020.
The fix changes the implementation so out‑of‑range indexes are routed through the jump table itself; fixed versions also refuse to compile a br_table with more than 65,520 targets.
Your scanner finds 4,000 vulns. Which 12 matter?
Nubivance is a Rapid7 Registered Partner delivering vulnerability management as a service - scanning, risk-based prioritization, and remediation follow-through across IT and OT.
Fix the backlogVersions, support lines, and lingering vulnerable builds
Wasmtime’s project uses numbered release lines and supports LTS branches for two years. Only the 36, 48, 49, and 50 release lines were still supported at the time of the advisories. The fixes were released at different times, so whether a host is safe depends on its release line and — for the ARM64 bug — the processor architecture.
- Fixed releases by line: update to 36.0.19, 48.0.7, or 49.0.4. Wasmtime 50.0.0, released on October 20, is fixed for both flaws.
- Unsupported lines received no fix; the 24.x LTS line — which reached end of support on August 20, 2026 — was not patched.
- ARM64 hosts that upgraded in April to 36.0.7, 42.0.2, or 43.0.1 to address an earlier Cranelift sandbox escape remain affected by CVE-2026-115893.
What operators and downstream projects must do: update then rebuild
Both advisories emphasize a practical wrinkle: Wasmtime is often embedded as a library. Updating the Wasmtime command‑line tool alone does not secure software that includes Wasmtime; every program that bundles the runtime must be rebuilt with a fixed Wasmtime release. The maintainers published no workaround in either advisory, and until a host is updated the attack vector is any module an outsider can supply.
Tooling signals are mixed: both flaws are recorded in RustSec as RUSTSEC-2026-0380 and RUSTSEC-2026-0379. As of October 26, GitHub’s advisory database had a reviewed entry for CVE-2026-115889 but not for CVE-2026-115893; GitHub notes only reviewed entries trigger Dependabot alerts, so Dependabot users should not expect an alert for the ARM64 flaw.
Who this touches: serverless platforms, maintainers, and downstream builders
Services that compile modules supplied by outsiders carry the highest exposure because both flaws require a module the attacker controls. The advisory cites Fastly as an example, saying Fastly’s Compute platform runs customer code using Wasmtime. Open‑source downstreams are already moving: Spin, a tool for building serverless WebAssembly apps that runs on Wasmtime, moved to Wasmtime 50.0.0 in Spin 4.2.4 on October 21.
For teams that package Wasmtime into other programs, the immediate checklist is short and strict: identify builds that include Wasmtime, confirm the Wasmtime version embedded, rebuild each product with a fixed release (36.0.19, 48.0.7, 49.0.4, or 50.0.0), and treat ARM64 deployments with particular scrutiny because CVE-2026-115893 is architecture‑specific.
The Bytecode Alliance scored both flaws 9.9 out of 10 for severity, but the maintainers also reported no observed attacks as of their advisories. Neither vulnerability was listed in CISA’s Known Exploited Vulnerabilities catalog as of October 26. Until services and embedded builds are rebuilt with fixed versions, the risk remains for any environment that compiles or runs WebAssembly modules supplied by outsiders.