External risk intelligence

Wasmtime Compiler Sandbox Escape Vulnerability on aarch64

CVE advisorySeverity: CRITICAL (CVSS 9.9)

CVE-2026-115893

Wasmtime is a WebAssembly runtime library used by diverse applications, ranging from server-side edge runtimes to local CLI tools and internal developer utilities. While it can be embedded in internet-facing services that execute untrusted Wasm code, it is not inherently a standalone network service or public-facing portal, making internet reachability dependent on the specific deployment context of the host application.

Halo Surface Signal: 3 out of 5 — possibly public-facing.

External exposure likelihood

Horizon Alert

Summary of the vulnerability and why it matters

This advisory addresses a critical vulnerability in the Wasmtime WebAssembly runtime, specifically affecting the Cranelift compiler on ARM processors. The issue could allow a malicious module to bypass security controls and execute arbitrary code, posing a significant risk if the runtime handles untrusted code. The main concern is confirming relevance and exposure within our specific deployment contexts.

  • A critical flaw in WebAssembly runtime.
  • It could allow code to bypass security.
  • Confirm if our systems are affected.

Attack Path

How an attacker could exploit the issue

An attacker could leverage a WebAssembly module to escape the sandbox environment of the Wasmtime runtime on aarch64 systems. This is achieved by crafting a Wasm module that exploits an issue in how the Cranelift compiler backend handles a specific instruction, leading to a jump to arbitrary code.

  • Requires access to run Wasm modules.
  • Triggered by a specially crafted Wasm module.
  • Risk of arbitrary code execution.

Live Threat

Current exploitation, exposure, and threat context

When supported by the advisory, a user-controlled WebAssembly module could escape the sandbox on aarch64 engines using the default Cranelift backend. This may affect the integrity and confidentiality of the system and user data.

  • Arbitrary code execution on the host system.
  • Malicious Wasm module bypasses sandbox.
  • Sandbox escape impacts system integrity.

Operational Fix

Recommended remediation, mitigation, and detection steps

This vulnerability impacts Wasmtime, a WebAssembly runtime. Ownership likely resides with teams managing applications that embed Wasmtime, potentially platform or development teams. The first practical step is to inventory Wasmtime deployments, assess their exposure, and confirm reachability and criticality to prioritize remediation efforts.

  • Identify Wasmtime deployments and owners.
  • Verify sandbox escape reachability and impact.
  • Plan phased remediation based on risk.

Supplementary metadata

Validate whether this threat affects your internet-facing exposure.

Halo Threat Intelligence helps prioritize remediation with Halo Surface Signal and H/A/L/O context. Start exposure validation with a free external attack surface trial.

Frequently asked questions

What is Wasmtime?

Wasmtime is a standalone runtime engine for WebAssembly. Developers use it to execute high-performance, sandboxed code across various environments, from server-side applications and edge computing platforms to local development tools. By isolating WebAssembly modules, it ensures that untrusted code can run safely without interfering with the host system's broader operations.

What does CVE-2026-115893 mean for sandbox security?

This vulnerability is classified as CWE-691 (Insufficient Control Flow Management). It occurs when the Cranelift compiler on aarch64 processors incorrectly handles complex branch instructions. If a Wasm module contains a specifically large number of targets, the runtime may miscalculate jumps, allowing the module to bypass its isolation boundary and execute arbitrary commands on the host machine.

How is this sandbox escape triggered?

An attacker triggers this by providing a specially crafted WebAssembly module containing a br_table instruction with an extremely high number of targets (around 256,000). The vulnerability specifically affects aarch64 systems using the default Cranelift compiler. Simply running small or standard WebAssembly modules that do not utilize this specific, massive instruction structure will not trigger the flaw.

Who should be concerned about this vulnerability?

You should care if your applications run untrusted WebAssembly code on ARM-based servers. According to Halo Surface Signal, Wasmtime is often embedded within larger software products rather than serving as a public-facing portal. Therefore, the risk depends heavily on whether your specific deployment exposes the Wasmtime engine to external user-provided modules.

What should I do first to address this issue?

Begin by auditing your infrastructure to identify where Wasmtime is embedded. Once you have a list of deployments, confirm which ones run on aarch64 architecture and whether they process input from untrusted sources. Finally, plan to update any identified instances of Wasmtime to versions 36.0.19, 48.0.7, 49.0.4, or newer, as these releases contain the necessary compiler fixes.

References