Wasmtime CVE-2026-115893

Exploitation requires the host to be running Wasmtime on an aarch64 (ARM64) target using the default Cranelift compiler backend, and the attacker must be able to supply and have the engine compile and run a Wasm module containing a br_table instruction with more than approximately 256,000 targets. Limiting factors that reduce realistic exposure: non-aarch64 engines (e.g. x86-64) are not affected and non-Cranelift backends are out of scope; the attacker needs the ability to get an untrusted module executed (PR:L - control over a submitted Wasm module, not pre-existing OS access). All Wasmtime/Cranelift versions supporting aarch64 since 2020 are affected up to the fixed releases 36.0.19, 48.0.7, and 49.0.4. Per the advisory, upgrading to a fixed version is the remedy; no separate workaround is stated.

This is a genuine high-priority issue, not a high-CVSS-but-low-real-risk inflation. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H, 9.9) describes a low-complexity, low-privilege attack with a scope change and full confidentiality/integrity/availability impact - consistent with a WebAssembly sandbox escape where a guest module breaks out to execute arbitrary host code. The vuln.today Decision label is act_now, the patch is confirmed available from the vendor, and the GHSA advisory confirms that ANY Wasmtime engine on aarch64 with default settings is affected, across all versions since aarch64 support shipped in 2020. Counter-signals and missing data: no CISA KEV listing and no EPSS score were supplied, so there is no evidence of active or widespread exploitation at this time - exploitation status is therefore 'no public exploit identified at time of analysis.' The PR:L in the CVSS vector reflects that the attacker must be able to supply and run a Wasm module; whether that is reachable network-wide (AV:N) depends entirely on the deployment (e.g. a service that executes untrusted user-submitted modules) - verify against your actual exposure. The qualifier that most bounds real-world risk is the platform: only aarch64 hosts using the default Cranelift backend are affected, and x86-64 deployments are not. For operators running untrusted Wasm on ARM servers/edge nodes this is a critical, patch-immediately defect; for x86-only fleets the practical risk is effectively nil.

An attacker who can submit a WebAssembly module to a service running Wasmtime on an aarch64 host (for example an edge-compute or plugin platform that executes untrusted modules) crafts a module containing a single br_table instruction with more than approximately 256,000 targets. Cranelift miscompiles the conditional branch so the jump lands at an attacker-controlled offset, letting the module escape the sandbox and run arbitrary code with the host process's privileges. No public exploit code was identified in the supplied data; the only referenced code artifacts are the vendor's fix PRs and commits.