CVE-2026-115893

Wasmtime: Cranelift backend on aarch64 can jump to incorrect target on large Wasm `br_table` instruction

No known exploitation. EPSS puts it in the 63rd percentile. No fix published yet.

CVSS 3.19.9Critical EPSS percentile63rd1.0% chance in 30 days CISA KEVNot listedNo confirmed exploitation
No public exploit known FixNone yetNo fix or workaround published

Check it yourself

No ready-made check. Neither Nuclei nor OpenVAS has one for this CVE yet.

Request a scan

Published 2026-10-23Updated 2026-10-29Sources: CVE.org, NVD

NVD CVE.org

What to do

No fixed build or workaround is published yet. Limit exposure and watch for a patch.

Bytecodealliance WasmtimeAffected: < 36.0.19Upgrade to: not statedAffected: >= 37.0.0, < 48.0.7Upgrade to: not statedAffected: >= 49.0.0, < 49.0.4Upgrade to: not statedStated by: CVE record

Versions as the sources state them. Full version matrix after sign-in

Steps

Written by AI from the record

Check whether your applications or services embed Wasmtime and run on aarch64 (Apple Silicon or ARM-based) servers using the default Cranelift compiler backend.
If you don't run Wasmtime or don't execute untrusted WebAssembly modules, no action is needed.
If affected, contact your software vendor or development team to confirm which Wasmtime version is in use and request an upgrade to a fixed release.
Until a fix is confirmed, avoid running untrusted or third-party WebAssembly code on aarch64 systems.

May need vendor or contractor work

Is your organisation exposed?Request an assessment to establish which checks fit your systems.

What it is

From the CVE record

Wasmtime is a runtime for WebAssembly. Prior to 36.0.19, 48.0.7, and 49.0.4, the Cranelift compiler backend on aarch64 can compile a Wasm br_table instruction with more than approximately 256,000 targets so that it has an incorrect conditional branch target. The branch can then jump to arbitrary other code at a user-controlled offset, allowing a user-controlled Wasm module to escape the sandbox on aarch64 engines using the default Cranelift backend. This issue is fixed in versions 36.0.19, 48.0.7, and 49.0.4.

In plain language

Written by AI from the record

This is a flaw in Wasmtime, a tool used to safely run WebAssembly code, that could let a malicious program break out of its sandbox on certain Apple/ARM-based servers — most businesses that don't run this software are not affected, but if you do, this needs attention soon.

Sandbox escape in Wasmtime's Cranelift aarch64 backend: a crafted Wasm `br_table` with over ~256,000 targets causes an incorrect conditional branch computation, letting attacker-controlled Wasm redirect execution to arbitrary code and escape the sandbox.

If you're affected

Full host system compromise
Sandbox/isolation bypass
Arbitrary code execution
Operational disruption

What is it

Wasmtime is like a sealed sandbox that lets a computer safely run small programs (WebAssembly code) without letting them touch anything else on the machine. This bug is a crack in that seal on certain ARM-based servers: a specially crafted program could use it to jump out of the sandbox and take control of the surrounding system, like a prisoner finding a gap in a supposedly secure cell.

Who is affected

This matters to you if your product, platform, or infrastructure embeds Wasmtime to execute WebAssembly modules, and that infrastructure runs on aarch64 (ARM/Apple Silicon) hardware using the default Cranelift compiler backend. It is only a real risk if your system actually loads and runs WebAssembly modules that could come from an untrusted or external source — if you never run third-party Wasm code, exposure is minimal.

How urgent is it

There is no evidence yet of attackers exploiting this in the wild, no public exploit code, and it is not on any government list of actively exploited vulnerabilities, so this is not an emergency drop-everything situation. That said, the technical severity is very high — a successful exploit lets attacker code break out of its intended sandbox — so if you run Wasmtime on affected hardware, you should prioritize confirming your exposure and remediation plan promptly rather than putting it off indefinitely.

What to do — in detail

Inventory all services/products embedding Wasmtime, noting the compiler backend (Cranelift) and target architecture (aarch64 vs x86_64) — only aarch64 with the default Cranelift backend is affected.
Our findings do not confirm a published patch version; verify directly with the Wasmtime project/advisory (bytecodealliance/wasmtime) for the current fixed release before upgrading, since the exact fixed version could not be confirmed from the data available to us.
As a temporary mitigation while awaiting confirmed patch guidance: avoid executing untrusted or externally-sourced Wasm modules on aarch64 hosts, or restrict br_table complexity if you control module generation, or run on x86_64 hosts / with an alternative backend (e.g., Winch) if feasible.
No CISA KEV listing exists, so there is no federal remediation deadline; treat this as a standard high-severity (CVSS 9.9) patch-management item.
Monitor the Wasmtime security advisories page and your dependency scanners for an official fixed release, and re-verify exposure once one is published.

Technical context

CVSS 9.9 (Critical), AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H — network-exploitable with low privileges, no user interaction, and scope change (sandbox escape) causing full confidentiality/integrity/availability impact. Weakness class is CWE-691 (Insufficient Control Flow Management). Root cause: Cranelift's aarch64 code generation for Wasm br_table miscomputes a jump table offset for tables exceeding ~256,000 entries, producing an out-of-bounds/incorrect branch target reachable by attacker-controlled Wasm input. EPSS places predicted exploitation likelihood in the lower range with a flat trend, consistent with no observed in-the-wild exploitation, no KEV listing, and no public PoC — exploit maturity is theoretical/unweaponized at this time. Press attention is newly emerging but reflects disclosure coverage, not confirmed exploitation.

This is a general assessment based on public vulnerability data. It does not account for your specific infrastructure — when in doubt, consult a security specialist.

Exploitation

Where each signal puts this CVE on the scale from published to confirmed exploited.

EPSS63rd

CISA KEV

Not in the catalog. CISA has not confirmed exploitation.

Public exploits

No public exploit or proof of concept found in the sources we track.

EPSS

1.0% chance of exploitation activity in the next 30 days, which ranks it in the 63rd percentile of scored CVEs.

Exploit Prediction Scoring System, FIRST.org. A probability, not a confirmation.

Lifecycle

4 events over 6 days, from the signal feeds we watch.

2026-10-29Record updated
2026-10-23Publishedweakness classified, record updated

Affected products

bytecodeallianceoss-project
- wasmtimeLibraryLibraryOSS Libraries / generic-library

Technical detail

CVSS 3.1 vector

Open in the CVSS calculator

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

Scored 9.9 by NVD.

How it is reached

Attack Vector NetworkExploitable remotely over the network without any special conditions
Attack Complexity LowNo special conditions — the attack can be reliably reproduced
Privileges Required LowRequires basic user-level privileges
User Interaction NoneNo user interaction needed — fully automated exploitation

Scope

Scope ChangedThe exploit can affect other components (e.g. sandbox escape, host compromise from VM)

Impact if exploited

Confidentiality HighTotal information disclosure — all data in the component is compromised
Integrity HighTotal loss of integrity — attacker can modify any data in the component
Availability HighTotal denial of service — the component is completely unavailable