Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🦀
🦀 crates.io
Not in CISA KEV
CRITICAL severity

CVE-2026-115893 — wasmtime

CRITICALFix: bytecodealliance/wasmtime@222ff3a

CVE-2026-115893 is a critical-severity (CVSS 9.9) CWE-691 vulnerability in wasmtime. A fix is available for wasmtime — see the affected versions and patch details below.

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

Also known asGHSA-mghf-wjfp-p5xmRUSTSEC-2026-0379
Published
Updated
Affected
3 pkgs
Patched
3 / 3
Exploits
None indexed
Exploitation data as of Oct 29, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

No confirmed exploitation observed yet

  • A successful exploit gives an attacker total control of the affected component, not partial access.
  • CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.

Exploitation and automatability from CISA’s SSVC triage for CVE-2026-115893.

EPSS Exploitation Probability

via FIRST.org ↗
1.0%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs62th percentile — riskier than 62% of all scored CVEsHighest risk

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

CVE-2026-115893 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.

Where this sits among everything scored

Of 397,508 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.

Real-World Exposure

3 pkgs affected
🦀wasmtime🦀wasmtime🦀wasmtime

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects crates.io packages — download data is not available via public APIs for these ecosystems.

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.

Affected Packages

3 total 3 fixed
EcosystemPackageVulnerable rangeFix
🦀crates.iowasmtimeall versions36.0.19cargo update -p wasmtime --precise 36.0.19
🦀crates.iowasmtime≥ 37.0.0&&< 48.0.748.0.7cargo update -p wasmtime --precise 48.0.7
🦀crates.iowasmtime≥ 49.0.0&&< 49.0.449.0.4cargo update -p wasmtime --precise 49.0.4

Detection & mitigation playbook

Open-source dependency

  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for wasmtime, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update wasmtime to 36.0.19 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-115893 is resolved across your whole dependency graph.

  3. Workarounds

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

Fixing This On Your OS

If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.

Red HatImportant

Red Hat rates this vulnerability as Important because an attacker executing untrusted WebAssembly bytecode can bypass runtime sandbox restrictions and achieve arbitrary code execution in the context of the host process. The risk is constrained primarily to 64-bit ARM (aarch64) environments that evaluate untrusted or…

Workaround published by Red Hat
Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base, or stability.
Source: Red Hat security advisory for CVE-2026-115893 (CC BY 4.0)

Frequently Asked Questions

## 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 re
O3 Security · Impact-Aware SCA

Is CVE-2026-115893 in your dependencies?

Find it across crates.io, including transitive dependencies.

Scan my dependencies How O3 SCA works
CVE-2026-115893: wasmtime RCE — Fixed in 36.0.19