Organizations running untrusted WebAssembly on Arm hosts should check a separate critical Wasmtime flaw, not assume that remediation for another recent compiler bug closes every sandbox-escape path. In its October 19, 2026 advisory, the Wasmtime project describes CVE-2026-115893: a Cranelift code-generation defect on aarch64 that can let a crafted module redirect execution outside its sandbox. The maintainer rates it 9.9 under CVSS 3.1.

What is affected

The issue concerns the Cranelift compiler backend on aarch64. A Wasm module containing more than roughly 256,000 targets in a single br_table instruction can be compiled with an incorrect conditional branch target. Maintainers say the resulting branch can jump to other code at a user-controlled offset, enabling arbitrary sandbox escape. Their impact statement covers default Wasmtime engines on aarch64 and says the defect dates to the initial aarch64 support in 2020, before Wasmtime 1.0.

The advisory lists affected releases as versions below 36.0.19; versions from 37.0.0 up to, but not including, 48.0.7; and versions from 49.0.0 up to, but not including, 49.0.4. The documented patched releases are 36.0.19, 48.0.7 and 49.0.4. Select a fixed release appropriate to the application's supported branch and verify the actual deployed dependency.

Do not confuse the two compiler defects

Bulwark's earlier Wasmtime report addressed CVE-2026-115889, an SSA-index problem. This advisory covers a different CVE, a different compilation failure and an architecture-specific exposure. In particular, moving to version 43 to address the earlier SSA issue does not establish that an aarch64 deployment is fixed for this br_table defect: version 43 falls within this advisory's affected range.

This is follow-up patch guidance for an advisory published October 19, not a claim of a newly discovered October 29 attack. The reviewed maintainer notice does not report exploitation in the wild. It also does not establish that every service using WebAssembly accepts attacker-controlled modules or exposes the same host resources.

Actions for SMBs and government contractors

  1. Find the execution path. Ask application owners and suppliers whether production workloads use Wasmtime with Cranelift on aarch64, and whether customers, plugins or other less-trusted parties can supply Wasm modules. Include embedded runtimes and managed services; a standalone executable inventory is not enough.
  2. Patch the running artifact. Deploy the appropriate documented fixed release. Rebuild and redeploy applications or containers that embed Wasmtime, then verify their runtime version and architecture. A changed lockfile is not proof that production workers have been replaced.
  3. Limit exposure while remediation is pending. Where operationally feasible, suspend untrusted-module submission or restrict it to reviewed inputs. This is temporary risk reduction, not a maintainer-certified workaround. Do not rely on the sandbox as the sole boundary protecting sensitive host data.
  4. Review host authority. Minimize runtime service-account permissions, accessible secrets, network reach and filesystem mounts. For multi-tenant or sensitive contract workloads, check what independently enforced isolation would still contain a compromised runtime process.
  5. Preserve investigation records. Retain available module-submission, build and execution telemetry. Investigate unexplained host activity through normal incident-response procedures. A large module or a crash alone is not a confirmed malicious indicator.

Bulwark assessment

The operational lesson is to track remediation by vulnerability, compiler backend, architecture and deployed release, rather than closing a generic 'Wasmtime patched' ticket. A fix that resolves one sandbox defect may leave another path open. Prioritize systems that execute less-trusted modules and can reach privileged credentials or sensitive data; verify both the engine update and the limits on host access.

Original source

Wasmtime maintainer advisory GHSA-mghf-wjfp-p5xm: Cranelift backend on aarch64 can jump to an incorrect target on a large Wasm br_table instruction, published October 19, 2026. The affected ranges, fixed releases and technical impact above come from this primary notice.