Wasmtime Cranelift Sandbox Escapes CVE-2026-115889 and CVE-2026-115893: Update to 36.0.19, 48.0.7, 49.0.4 or 50.0.0

On 19 October 2026, the Bytecode Alliance's Wasmtime project published two security advisories for flaws in Cranelift, the compiler Wasmtime uses by default to turn WebAssembly (Wasm) code into machine code. Both flaws can let a specially crafted Wasm module escape the sandbox that is meant to contain it. CVE-2026-115889 affects every processor architecture; CVE-2026-115893 affects only 64-bit ARM (aarch64) hosts. GitHub, the CVE Numbering Authority (CNA) for the project, scores each flaw CVSS 3.1 9.9 Critical (GHSA-897f-g5gm-fmxm; GHSA-mghf-wjfp-p5xm). Fixed releases are out for every supported release line.

The risk is real but narrow. An attacker first needs a vulnerable Wasmtime build to compile a module they control, so the exposure sits with services that run Wasm written by someone else: edge and serverless platforms, plugin systems and multi-tenant hosts. As of 27 October 2026, 08:17 Israel time (UTC+2), CVE-2026-115889 and CVE-2026-115893 are not in CISA's Known Exploited Vulnerabilities (KEV) catalog, CISA's assessment on the CVE-2026-115889 record lists exploitation as "none", and no source we checked reports attacks. The maintainers list no workaround, so updating, and rebuilding any software that embeds Wasmtime, is the fix.

Technical Information

What Wasmtime is. Wasmtime is an open-source runtime that runs WebAssembly outside the browser. It ships as a command-line tool and, more often, as a Rust library built into other software. Its job is to keep each Wasm module inside set limits: a module can use only its own memory and the host functions it is given. The project's security policy says "Anything that undermines the Wasm execution sandbox is a security vulnerability" (Wasmtime security policy).

CVE-2026-115889: silent overflow in Cranelift (any architecture). Per the advisory, Cranelift before Wasmtime 43 "bit-packs its SSA value indices in a way that can result in silent overflow in release builds," leading to "incorrect value references" and "arbitrary miscompilation." The advisory says "a very large Wasm function body, or one that is specially crafted to use many SSA values, can use this to force type-confusion or other arbitrary side-effects and escape the sandbox," and that "a Wasmtime engine with default settings (using the Cranelift backend) on any architecture/platform could experience a sandbox escape." The main development line had already removed the problem: pull request #12613, merged on 18 February 2026, widened the packed fields from 24 to 32 bits and shipped in Wasmtime 43.0.0 on 20 March. Its description presents the change as a capacity improvement and does not mention security. The 36.x long-term support (LTS) line received the fix in 36.0.19 on 19 October. The advisory does not say when the security impact was recognised.

CVE-2026-115893: wrong branch target on aarch64. Per the advisory, on aarch64 Wasmtime "can compile a Wasm module with more than ~256k targets on one br_table instruction in a way that results in an incorrect conditional branch target," which "could then jump to arbitrary other code (at an user-controlled offset), leading to arbitrary sandbox escapes." br_table is the Wasm instruction that jumps to one of many locations based on an index. The fix, pull request #14826, explains that the branch for out-of-range indexes "has a +/- 1MiB range," so a very large jump table could make it "silently wrap the offset." The advisory says "all versions of Wasmtime/Cranelift that support aarch64, since the initial release of that support in 2020 (before Wasmtime v1.0), are affected." The same pull request adds an implementation limit: fixed versions refuse to compile a br_table with more than 65,520 targets, which the code comment says matches the limit V8 and SpiderMonkey impose.

The CVSS vector for both is AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H. "Privileges required: low" reflects the need to get a module compiled; "scope: changed" reflects code breaking out of the sandbox into the host. The advisories do not name affected services or say what an attacker could reach after an escape.

Exploitation status. CISA's assessment attached to the CVE-2026-115889 record on 26 October lists exploitation "none", automatable "no" and technical impact "total" (NVD). The CVE-2026-115893 record carries no CISA assessment yet (NVD). Both are not in KEV (see Sources for the check time). We found no national CERT advisory for either flaw.

Timeline (Israel time, UTC+3 until 25 October and UTC+2 after):

• 18 February 2026: Pull request #12613 widens Cranelift's value fields on the main line; it ships in Wasmtime 43.0.0 on 20 March.
• 19 October, 22:09–22:20: Wasmtime 36.0.19, 48.0.7 and 49.0.4 are released (36.0.19; 48.0.7; 49.0.4).
• 19 October, 22:21: The project publishes both advisories.
• 20 October, 19:22: Wasmtime 50.0.0, the regular monthly release, ships with the aarch64 fix (release notes). RustSec issues RUSTSEC-2026-0379 and RUSTSEC-2026-0380 the same day.
• 24 October, 00:23–01:16: GitHub publishes the CVE records (CVE-2026-115889; CVE-2026-115893) and they reach NVD.
• 26 October, 17:40: CISA adds its assessment to the CVE-2026-115889 record.

Affected Product Versions

Per the two advisories and the CVE records. Wasmtime publishes a new major version on the 20th of each month; every version that is a multiple of 12 is an LTS release supported for 24 months, others for 2 months, and "security bugs are guaranteed to be backported to all supported releases" (Wasmtime release process).

Notes:

• An earlier aarch64 fix is not enough. Hosts that moved to 36.0.7, 42.0.2 or 43.0.1 in April to fix an earlier aarch64 Cranelift sandbox escape are still inside the affected range for CVE-2026-115893.
• Embedded copies need a rebuild. Wasmtime is usually compiled into other programs as a library. Updating the wasmtime command-line tool does not fix them; each program needs to be rebuilt against a fixed crate version. (Rescana guidance)
• Linux distribution packages may lag. As of 27 October, Debian's security tracker lists its rust-wasmtime packages (26.0.1 in trixie, 36.0.13 in forky and sid) as vulnerable and unfixed (Debian tracker).
• Exposure is not compromise. A host that only runs Wasm modules it builds and trusts itself has far less exposure than one that compiles modules from customers or the internet.

Workaround and Mitigation

1. Update. Move every Wasmtime deployment and every program that embeds Wasmtime to 36.0.19, 48.0.7, 49.0.4, 50.0.0 or later. Neither advisory lists a workaround.

2. Find the embedded copies. Search Rust Cargo.lock files for the wasmtime crate. RustSec lists both flaws (RUSTSEC-2026-0380; RUSTSEC-2026-0379), so cargo audit will flag them. As of 27 October 08:06 Israel time, GitHub's advisory database had a reviewed entry for CVE-2026-115889 (GHSA-897f-g5gm-fmxm) but none for CVE-2026-115893, so teams that rely only on Dependabot alerts may not be told about the aarch64 flaw. (Rescana guidance)

3. Prioritise hosts that run other people's code. Update first where outsiders can supply Wasm modules: multi-tenant edge or serverless platforms, plugin and extension hosts, and CI or build services that compile third-party modules. Within those, prioritise aarch64 machines, which are exposed to both flaws. (Rescana guidance)

4. Plan for one behaviour change. Fixed versions reject any br_table with more than 65,520 targets (pull request #14826). Modules above that limit will fail to compile after the update; normal modules are not expected to come close. (Rescana guidance)

5. Ask your platforms. If you run code on a supplier's WebAssembly platform, ask which Wasmtime version it runs and when it updated. For example, Fastly says its Compute platform runs customer code "using Wasmtime" (Fastly documentation); Fastly has not published a statement on these flaws that we found, and we do not suggest it is affected. (Rescana guidance)

Indicators of Compromise

The Wasmtime project, NVD and CISA have published no indicators of compromise, and no source we checked reports exploitation. None of the sources maps these flaws to MITRE ATT&CK, and we have not done so either. Platform operators can review upload logs for unusually large Wasm modules, or modules that failed to compile after the update because of the new br_table limit. These are hunting ideas, not confirmed signs of attack. (Rescana guidance)

What we will update

We will update this post if CISA adds either CVE to the KEV catalog, if the Wasmtime project, CISA or a national CERT reports exploitation, if NVD publishes its own scores, if a major WebAssembly platform publishes a statement on these flaws, or if the project revises its advisories.

Sources

• Wasmtime project (Bytecode Alliance): GHSA-897f-g5gm-fmxm, "Bit-packing in Cranelift compiler causes silent overflow and miscompilation" (19 October 2026): https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-897f-g5gm-fmxm; GHSA-mghf-wjfp-p5xm, "Cranelift backend on aarch64 can jump to incorrect target on large Wasm br_table instruction" (19 October 2026): https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-mghf-wjfp-p5xm; release notes 36.0.19, 48.0.7, 49.0.4, 50.0.0, 43.0.0; pull requests #12613 and #14826; release process; security policy; earlier aarch64 advisory GHSA-jhxm-h53p-jm7w
• CVE Program, NVD and CISA: CVE records, GitHub as CNA (CVE-2026-115889, CVE-2026-115893); NVD entries (CVE-2026-115889, Deferred, CISA assessment attached; CVE-2026-115893, Deferred); CISA KEV: CVE-2026-115889 and CVE-2026-115893 are not in KEV (catalog version 2026.10.26, checked 27 October 2026, 08:17 Israel time): https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• Package and distribution trackers: RustSec Advisory Database (RUSTSEC-2026-0380, RUSTSEC-2026-0379); GitHub Advisory Database reviewed entry GHSA-897f-g5gm-fmxm; Debian security tracker (CVE-2026-115889, CVE-2026-115893)
• Fastly: Compute getting-started guide: https://www.fastly.com/documentation/guides/compute/getting-started-with-compute/
• The Hacker News: "Two Critical Wasmtime Flaws Could Let Malicious WebAssembly Modules Escape Sandboxes" (26 October 2026), which first drew our attention to the story; every fact above was checked against the project's own pages: https://thehackernews.com/2026/10/two-critical-wasmtime-flaws-could-let.html

A WebAssembly sandbox is often the only wall between one customer's code and another's on an edge or serverless platform, so an escape matters most at the suppliers you trust to run code for you. A supplier that can quickly say whether it runs Wasmtime, on which version and which CPUs, is showing that it knows its own stack.

Forward this to your TPRM owner: Send suppliers that run your code, or let you run code on their platforms, a short, friendly check (Rescana guidance):

• Do you run Wasmtime anywhere, directly or inside a platform you operate, to execute code you did not write? Which version?
• Have all programs that embed Wasmtime been rebuilt on 36.0.19, 48.0.7, 49.0.4, 50.0.0 or later?
• Do any of those hosts run on aarch64 (64-bit ARM)?
• Does your dependency scanning cover CVE-2026-115893, given that GitHub's advisory database had no reviewed entry for it as of 27 October?

Want a fast, evidence-based view of how your suppliers handle runtime and sandbox fixes like these? Book a demo.