critical · 9.9 Patched

Wasmtime: Cranelift backend on aarch64 can jump to incorrect target on large Wasm `br_table` instruction

CVE-2026-115893 · GHSA-mghf-wjfp-p5xm · RUSTSEC-2026-0379 · published 19 Oct 2026

How serious is it

  • Severity: critical, CVSS score 9.9 out of 10.
  • No exploit prediction (EPSS) score yet.
  • Not on the CISA list of exploited vulnerabilities.
  • No public exploit in Exploit-DB.

Is your app affected by CVE-2026-115893?

Paste this prompt into Claude Code, Cursor or any AI coding tool: it runs a free Shippable scan of your project and fixes what it finds. Built with Lovable, Bolt or v0? Scan your live app. Or upload your package file.

Who is affected

  • wasmtime (crates.io) < 36.0.19
  • wasmtime (crates.io) >= 37.0.0, < 48.0.7
  • wasmtime (crates.io) >= 49.0.0, < 49.0.4

How to check

  1. Run cargo tree -i wasmtime in your project to see the installed version, including copies pulled in by other packages.
  2. Or paste your lockfile into the checker: it lists every package with a known vulnerability, this one included.

How to fix

Copies a prompt for Claude Code, Cursor or Codex: it checks your lockfiles for this and upgrades it.
  1. On < 36.0.19: Upgrade wasmtime to 36.0.19 or later, commit the lockfile and redeploy.
  2. On >= 37.0.0, < 48.0.7: Upgrade wasmtime to 48.0.7 or later, commit the lockfile and redeploy.
  3. On >= 49.0.0, < 49.0.4: Upgrade wasmtime to 49.0.4 or later, commit the lockfile and redeploy.
  4. If a vulnerable version was live, check your logs and rotate the secrets that server could read.

The advisory

## 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.

Check your whole app

Dependencies are only half of it. Free and read-only: before you push, run npx shippable-dev scan localhost:3000 in your project folder, no account needed. For your live app, you prove it's yours with a one-line tag first.

References

Merged from OSV, GitHub Advisory Database. Last updated 29 Oct 2026. All vulnerabilities · RSS · JSON

Get alerts for new exploited vulnerabilities