CVE-2026-115893: 
Linux Debian vulnerability analysis and mitigation

CVE-2026-115893 is a sandbox escape vulnerability in Bytecode Alliance's Wasmtime WebAssembly runtime, specifically affecting the Cranelift compiler backend on aarch64 targets. When a WebAssembly module contains a br_table instruction with more than approximately 256,000 targets, the Cranelift backend generates an incorrect conditional branch target, allowing execution to jump to arbitrary code at a user-controlled offset. This flaw affects all Wasmtime versions prior to 36.0.19, versions 37.0.0 through 48.0.6, and versions 49.0.0 through 49.0.3. The vulnerability has been present since the initial aarch64 support was added in 2020 (before Wasmtime v1.0). It carries a CVSS v3.1 base score of 9.9 (Critical) (GitHub Advisory, Feedly).

The root cause is classified as CWE-691 (Insufficient Control Flow Management). The Cranelift aarch64 backend implements br_table using a JTSequence macro-instruction that includes a conditional branch for the out-of-bounds (default) case. On aarch64, this conditional branch has a limited ±1 MiB range. When a br_table instruction has more than ~256,000 targets, the accompanying offset table of 32-bit entries exceeds this range, causing the conditional branch to silently wrap its offset and land on an incorrect target. The fix replaces the conditional branch with a conditional-select instruction that clamps the selector index to the last table entry (which is filled with the default target), eliminating the range limitation entirely (GitHub Advisory, Fix PR #14826). Exploitation requires only low privileges — an authenticated user capable of submitting a crafted Wasm module to an aarch64 Wasmtime engine using the default Cranelift backend.

Successful exploitation allows a user-controlled WebAssembly module to fully escape the Wasmtime sandbox on aarch64 systems, achieving arbitrary code execution in the host process context. This results in high impact to confidentiality, integrity, and availability — an attacker can read host memory and secrets, modify host state, and potentially crash or take over the host process. Given that Wasmtime is widely embedded in serverless platforms, plugin systems, and blockchain runtimes, a sandbox escape could enable lateral movement to other tenants or host infrastructure (GitHub Advisory, Feedly).

As of the time of disclosure, there is no public proof-of-concept exploit and no evidence of in-the-wild exploitation (Feedly). The EPSS score is 0.0, reflecting low current exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. However, the attack complexity is low and only low privileges are required, making weaponization feasible for a motivated attacker with knowledge of aarch64 Cranelift internals. The vulnerability has been tracked as RUSTSEC-2026-0379 in the Rust security advisory database (OSV).

1. Identify target: Locate a service running Wasmtime on an aarch64 host (e.g., ARM-based cloud instances, Apple Silicon servers) using the default Cranelift compiler backend, accepting user-supplied WebAssembly modules.
2. Craft malicious Wasm module: Construct a WebAssembly binary containing a br_table instruction with more than ~256,000 branch targets. This can be done programmatically using a Wasm binary encoder (e.g., wasm-encoder in Rust or wabt tooling).
3. Trigger compilation: Submit the crafted Wasm module to the target Wasmtime engine. Cranelift compiles the br_table into a JTSequence with an out-of-range conditional branch whose offset wraps, producing a branch to an attacker-influenced code location.
4. Control branch destination: By carefully sizing the offset table (i.e., controlling the number of targets), the attacker influences where the wrapped branch lands relative to the compiled code region, redirecting execution outside the sandbox.
5. Achieve arbitrary code execution: The misdirected branch executes host code outside the WebAssembly sandbox, enabling the attacker to run arbitrary instructions in the host process, exfiltrate data, or establish persistence (GitHub Advisory, Fix PR #14826).

• Process: Unexpected child processes or system calls originating from the Wasmtime host process (e.g., shell spawning, network connections initiated by the Wasm runtime process).
• File System: Unusual files written by the Wasmtime process to directories outside expected Wasm sandbox paths; new executables or scripts created by the runtime user account.
• Network: Outbound connections from the Wasmtime host process to unexpected external IPs, particularly shortly after Wasm module submission.
• Logs: Submission of unusually large WebAssembly modules (multi-megabyte binaries with extremely large br_table sections) in application or API access logs; runtime errors or crashes in Wasmtime logs preceding anomalous behavior.
• Memory/Crash Artifacts: Unexpected segmentation faults or memory corruption signals from the Wasmtime process on aarch64 hosts, which may indicate failed exploitation attempts.

Bytecode Alliance has released patched versions: 36.0.19, 48.0.7, and 49.0.4. All users running Wasmtime on aarch64 systems should upgrade to one of these versions immediately (GitHub Advisory). If immediate patching is not possible, operators should restrict or disable execution of untrusted WebAssembly modules on aarch64 systems, or migrate workloads to non-aarch64 architectures as a temporary measure. Users on versions between 37.0.0 and 48.0.6 should upgrade to 48.0.7; those on 49.0.x should upgrade to 49.0.4; those on the 36.x long-term branch should upgrade to 36.0.19 (Feedly).

The vulnerability was reported by researcher ilyas-mallah and disclosed by Bytecode Alliance maintainer pchickey on October 19, 2026 via GitHub Security Advisory GHSA-mghf-wjfp-p5xm (GitHub Advisory). The fix was authored by cfallin, a core Cranelift contributor. The advisory generated downstream RUSTSEC-2026-0379 tracking issues across numerous Rust projects embedding Wasmtime, including RisingWave, smoldot, krustlet, and others (Fix PR #14826). Social media coverage appeared on Bluesky and infosec.exchange shortly after disclosure, reflecting community awareness of the critical severity rating.