Wasmtime runs WebAssembly, which is to say it runs code you do not trust and promises that the code cannot reach past the walls around it. Advisory GHSA-897f-g5gm-fmxm, published on 19 October, describes a way past the walls that does not involve attacking them.

CVE-2026-115889 is scored 9.9 with the vector AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H, and carries two weakness classes: CWE-197, numeric truncation, and CWE-843, type confusion.

What the bug is

Cranelift, the compiler backend Wasmtime uses by default, bit-packs the indices it uses to refer to values inside a function. Packing squeezes more than one field into a single machine word, and squeezing has a limit. Past that limit, in the advisory's words, the packing "can result in silent overflow in release builds", which is CWE-197, numeric truncation.

The index wraps, the compiler's intermediate representation ends up holding references to the wrong values, and the machine code it emits does something other than what the WebAssembly said. A very large function, or one crafted to use a great many values, gets there.

Note the phrase "release builds". A debug build has the assertion that would have caught this. The build everybody ships does not.

Why a compiler bug is a security bug here

For most software a miscompilation is a correctness problem. For a sandbox it is the whole product. Wasmtime's guarantees are not enforced by the runtime watching the guest at every step; they are compiled in, so the bounds checks, the type checks and the memory isolation all become instructions in the generated code. Which is why a flaw with no memory-safety bug anywhere in it scores 9.9.

A compiler that emits the wrong instructions has not broken a check. It has failed to write one down.

Which is why the advisory's impact line reads as it does: the flaw can lead to "a sandbox escape from a specially-crafted Wasm module", through type confusion or arbitrary side effects. The guest does not break out. The guest was never properly fenced in.

A Wasmtime engine with default settings using the Cranelift backend is affected on any architecture and any platform. There are no workarounds in the advisory.

The version range is awkward

Affected versions are everything below 36.0.19, and everything from 37.0.0 up to but not including 43.0.0. The patched release named is 36.0.19, and Cranelift was changed in v43 to remove the susceptibility entirely.

Read that carefully, because it leaves a gap. If you are on the 36 line, update within it. If you are on anything from 37 to 42, the advisory does not name a patch release for your line, and the remedy is moving to 43 or later. For a dependency that sits under a production workload, a seven-major-version jump is not a patch, it is a project.

The other two

The same day brought a second critical, GHSA-mghf-wjfp-p5xm, in which the Cranelift backend on aarch64 can jump to an incorrect target on a large Wasm branch table. 2 independent miscompilation bugs, published together, both reachable from guest code. 5 days earlier came a High-severity filesystem sandbox escape when renaming symlinks with trailing slashes.

Reporting of all this appeared on 26 October, a week after the advisories went out, which is the ordinary lag for a project that publishes properly and does not brief anybody in advance.

What to do

  • Check which Wasmtime version your dependency tree actually resolves to, not which one you think you pinned.
  • On the 36 line, move to 36.0.19.
  • On 37 through 42, plan the move to 43. There is no in-line patch named, and no workaround.
  • If you run untrusted guest modules from third parties, treat this as urgent. If your only Wasm is your own code, the attacker needs to get a module in first.
  • Review the two other advisories from the same window. A branch table miscompilation and a symlink escape are both reachable from a guest.

What is not established

  • Whether anyone has exploited it. Nothing has been reported.
  • Whether a practical exploit exists. The advisory describes the consequence, not a demonstration.
  • What happens on 37 through 42 beyond the advice to move to 43.
  • How many deployments run untrusted third-party modules, which is the population that matters.
  • Whether the two critical miscompilation bugs share a root cause or were found together by chance.