Wasmtime: Cranelift backend on aarch64 can jump to incorrect target on large Wasm `br_table` instruction
Affects wasmtimeSource GCVE Database
Not known to be exploited · CVSS 9.9 Critical : upgrade to 36.0.19 as a priority.
Data as of 28 Oct 2026, 22:12 UTC
- Patch
- Available – fixed in 36.0.19, 48.0.7, 49.0.4
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:HExploitation evidence
Disclosed: evidence found.
CVE published 23 Oct 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.
What to do
Upgrade wasmtime to 36.0.19; wasmtime to 48.0.7; wasmtime to 49.0.4.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| crates.iowasmtime | Affected
| Fixed in
|
| crates.iowasmtime | Affected
| Fixed in
|
| crates.iowasmtime | Affected
| Fixed in
|
Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.
Description
## Summary When running with the Cranelift compiler backend on an aarch64 target, Wasmtime can compile a Wasm module with more than ~256k targets on one `br_table` instruction in a way that results in an incorrect conditional branch target. This conditional branch could then jump to arbitrary other code (at an user-controlled offset), leading to arbitrary sandbox escapes. ## Impact Any Wasmtime engine running on aarch64 with default settings can be forced to jump to arbitrary code by a user-controlled Wasm module. All versions of Wasmtime/Cranelift that support aarch64, since the initial release of that support in 2020 (before Wasmtime v1.0), are affected. ## Patches Wasmtime v36.0.19, v48.0.7, and v49.0.4 have been released which all fix this issue.
References
- github.com/bytecodealliance/wasmtime/security/advisories/GHSA-mghf-wjfp-p5xm (opens in a new tab)
- nvd.nist.gov/vuln/detail/CVE-2026-115893 (opens in a new tab)
- github.com/bytecodealliance/wasmtime/pull/14818 (opens in a new tab)
- github.com/bytecodealliance/wasmtime/pull/14819 (opens in a new tab)
- github.com/bytecodealliance/wasmtime/pull/14820 (opens in a new tab)
- github.com/bytecodealliance/wasmtime/pull/14826 (opens in a new tab)
- github.com/bytecodealliance/wasmtime/commit/222ff3a65dab9aa7011f8c246937751a0bac5abd (opens in a new tab)
- github.com/bytecodealliance/wasmtime/commit/994549891c8a706cb4f2809f9d17b9f67b31e618 (opens in a new tab)
- github.com/bytecodealliance/wasmtime/commit/e61df1b454be9313d61a5f8de07722a421139bbe (opens in a new tab)
- github.com/bytecodealliance/wasmtime/commit/f517bd6e890c7c1291ab9fe05d8cc0c9f11e56aa (opens in a new tab)
- github.com/bytecodealliance/wasmtime (opens in a new tab)
- github.com/bytecodealliance/wasmtime/releases/tag/v36.0.19 (opens in a new tab)
- github.com/bytecodealliance/wasmtime/releases/tag/v48.0.7 (opens in a new tab)
- github.com/bytecodealliance/wasmtime/releases/tag/v49.0.4 (opens in a new tab)
- rustsec.org/advisories/RUSTSEC-2026-0379.html (opens in a new tab)