On this page (7 sections)
Wasmtime, the WebAssembly runtime from the Bytecode Alliance, has a critical flaw in its Cranelift compiler backend on aarch64. According to the GitHub advisory, a Wasm module with a very large br_table instruction can be compiled with an incorrect branch target, which lets the module jump to other code and escape the sandbox.
If you run untrusted or customer-supplied WebAssembly on ARM64 servers (plugin systems, edge functions, multi-tenant platforms), this one is for you. If you only run Wasm you wrote yourself, the risk is lower but you should still update.
What happened
The Wasmtime maintainers published the advisory on October 19, 2026, and NVD published the CVE record on October 23. The advisory credits a reporter with the handle ilyas-mallah. When Wasmtime compiles a module on aarch64 using Cranelift, a br_table instruction with more than roughly 256,000 targets can end up with a wrong conditional branch target.
A br_table is WebAssembly's multi-way branch, similar to a switch statement. Normal programs rarely come close to that many targets, but a module written on purpose can. The advisory says the resulting branch can land on arbitrary code at a user-controlled offset, which breaks the isolation Wasm is supposed to provide.
Why it matters
The whole point of a Wasm runtime is to run code you do not fully trust inside a sandbox. The advisory states that any Wasmtime engine on aarch64 with default settings can be forced to jump to arbitrary code by a user-controlled Wasm module, leading to arbitrary sandbox escapes. The CVSS vector lists scope as changed, meaning the impact reaches beyond the Wasm sandbox into the host process.
The advisory also says all Wasmtime/Cranelift versions that support aarch64, since that support first shipped in 2020 (before Wasmtime v1.0), are affected. The advisory lists patched versions 36.0.19, 48.0.7 and 49.0.4. The research does not describe fixes for any other release line, so if you are on a version outside those lines, check the Wasmtime releases page for the current guidance.
Who is affected
- Affected: Wasmtime on aarch64 (for example ARM servers or Apple Silicon hosts) using the default Cranelift backend and loading Wasm from users, tenants or third parties.
- Likely lower exposure: x86-64 hosts. The research describes the flaw only for aarch64, so do not assume x86-64 is affected, but do not rely on that as a reason to delay updates.
- Embedded use: applications that bundle the wasmtime Rust crate or link it into another product. Updating the system package is not enough if your build pins an older crate version.
- Worth checking: tools and platforms built on Wasmtime. The research does not list specific downstream products, so check your vendors' advisories.
How to check your exposure
First confirm the architecture of each host. This prints the CPU architecture (run on the server); look for aarch64:
uname -mOn Linux, aarch64 is reported; on Apple Silicon macOS you may see arm64, which is the same architecture family. Next, find the Wasmtime version. If the CLI is installed, this prints the version, which you compare to the advisory's affected ranges:
wasmtime --versionIf you embed Wasmtime in a Rust project, this lists the resolved version from your lockfile (run in the project directory). Compare it to the advisory's affected ranges: below 36.0.19; 37.0.0 or higher but below 48.0.7; 49.0.0 or higher but below 49.0.4.
cargo tree -i wasmtime| Affected range | Patched version |
|---|---|
| Below 36.0.19 | 36.0.19 |
| 37.0.0 or higher, below 48.0.7 | 48.0.7 |
| 49.0.0 or higher, below 49.0.4 | 49.0.4 |
What to do now
0 of 7 done
For a Rust project, updating the dependency looks like this. It changes your lockfile entry, so run it in the project directory and review the diff before deploying:
cargo update -p wasmtimeDetection and monitoring
The research does not give indicators of compromise for this flaw, and no exploitation is reported in it, so there is no signature to hunt for. Practical steps are defensive: log which Wasm modules each host loads and from whom, alert on unusually large modules, and watch for unexpected crashes or odd child processes from the host that runs Wasmtime. A sandbox escape would give an attacker the privileges of the host process, so run Wasmtime with the least privilege you can, in a container or a dedicated unprivileged account.
If you also run public websites or APIs in front of these services, keep an eye on them with uptime and certificate monitoring and see our guide on small business website security.
Timeline
| Date (2026) | Event |
|---|---|
| Oct 19 | Advisory published in bytecodealliance/wasmtime |
| Oct 23 | CVE published by the National Vulnerability Database |
| Oct 28 | Reviewed and added to the GitHub Advisory Database; advisory last updated |
Only one independent publisher, the GitHub advisory, is covered in our research so far. Fixes are in the Wasmtime commits and releases linked from that advisory, including the v36.0.19 release.
Sources
This article is based on the public sources below. Details can change as vendors and researchers publish more; check the original advisories before acting on version numbers.