Wasmtime CVE-2026-115889

Requires the host to compile and run an attacker-supplied, untrusted Wasm module using Wasmtime's default Cranelift backend; the malicious module must contain a sufficiently large or specially crafted function with enough SSA values to overflow the previously 24-bit-packed value index. The flaw only manifests in release builds, where the overflow guard (debug_assert) is compiled out. Limiting factors: the attacker must control the Wasm input and reach a Wasmtime engine that JIT/AOT-compiles untrusted guests (per CVSS PR:L); hosts that only run trusted/first-party modules are not exposed. Not dependent on a specific CPU architecture - any platform using the default Cranelift backend is affected.

This is a genuine high priority, not an inflated CVSS score. The vendor GHSA advisory confirms a default-configuration sandbox escape in the Cranelift backend on any architecture, and the vuln.today decision label is act_now with a vendor patch available. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:C) is internally consistent with the mechanism: an attacker supplying an untrusted Wasm module (the PR:L privilege) can force miscompilation that breaks out of the sandbox (S:C scope change) with full C:H/I:H/A:H impact - a 9.9 is defensible. Signals that are MISSING: no EPSS probability and no CISA KEV status were provided in the input, so widespread-exploitation likelihood cannot be quantified. No PoC or working-exploit reference is present either - the only code references are the vendor fix PRs (12613, 14818) and commits, which are patches, not exploit code. So exploitation status is 'no public exploit identified at time of analysis' despite the critical score; the urgency here derives from the act_now decision label, confirmed default-config impact, and the sandbox-escape primitive, not from observed exploitation. One nuance worth noting to defenders: the flaw manifests specifically in release builds (the debug_assert overflow guard is compiled out), so it is a real-world production exposure even though debug builds would have panicked.

An attacker who can submit a WebAssembly module to a host that compiles untrusted guests with Wasmtime's default Cranelift backend (e.g. an edge/serverless platform or plugin host) crafts a function with enough SSA values to overflow Cranelift's bit-packed value indices. The silent overflow makes the compiler reference the wrong IR values, producing a miscompiled, type-confused native function that lets the guest read/write outside its sandbox and act with host privileges. No public exploit identified at time of analysis; only vendor fix commits are published.