This article was published on October 26, 2026
Preface: Why AMD and Intel heavily support Wasm ecosystems NVIDIA’s greatest competitive moat is not just their chips, but the CUDA ecosystem. It is incredibly difficult for software engineers to migrate complex Python/PyTorch codebases from CUDA to AMD’s ROCm or Intel’s OneAPI.
Background: Pastime is actively used in AI/LLM architectures. Wasmtime does not replace the raw GPU mathematical kernels; instead, it optimizes how the CPU manages the GPU orchestration workflow, data preparation, and security isolation.
To connect Wasmtime to a GPU Inference Engine, the standard, vendor-neutral bridge is the WASI-NN (WebAssembly System Interface for Neural Networks) specification.
• The WebAssembly Equalizer: By supporting runtimes like Wasmtime and the wasi-nn standard, companies like AMD and Intel can bypass the CUDA moat.
• If a cloud provider deploys Wasmtime, developers just write abstract wasi-nn code. The underlying host platform can switch the underlying execution engine from an NVIDIA GPU to an AMD Instinct GPU (or Intel Gaudi accelerator) seamlessly. Wasmtime acts as a universal abstraction layer that commoditizes the underlying silicon.
The following instructions require the use of the accompanying infographics.
The Guest Side (The Wasm App): Code compiled into [.]wasm that defines tensors and handles execution flow.
The Host Side (The Embedder / Runtime): The application utilizing Wasmtime to load the [.]wasm file, mapping wasi-nn requests to hardware backends via execution targets like gpu.
The infographic breaking down the mechanics of the recently disclosed CVE-2026-115893 vulnerability, which resides in Wasmtime’s Cranelift compiler backend and specifically impacts AArch64 (ARM64) architectures.
Core Vulnerability Breakdown:
1.The Trigger Point: When a host system utilizes Just-In-Time (JIT) compilation to load raw, uncompiled Wasm bytecode (represented as your_guest_ai_app_bytecode.wasm in the diagram), Wasmtime dynamically invokes Cranelift to translate it into native machine code.
2.Arithmetic Overflow & Truncation: If a malicious Wasm module includes a branch table (br_table) instruction containing more than approximately 256,000 jump targets, an internal counter within Cranelift overflows or undergoes incorrect truncation.
3.Sandbox Escape: This math error causes the compiler to generate faulty conditional branch instructions on AArch64. The application can then jump to arbitrary, user-controlled memory offsets—completely escaping the Wasm sandbox to execute arbitrary native code on the host engine.
Vulnerability details: [CVE-2026-115893] 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.
Official announcement: Please refer to the link for details – https://www.tenable.com/cve/CVE-2026-115893