A critical Wasmtime vulnerability can undermine the boundary used to contain untrusted WebAssembly. In an October 19 advisory, maintainers describe CVE-2026-115889, rated 9.9 under CVSS 3.1, as a Cranelift compiler flaw that can permit sandbox escape from a crafted Wasm module.

Scope and fixed versions

The advisory lists affected versions as below 36.0.19, and 37.0.0 through versions before 43.0.0. Wasmtime 36.0.19 fixes the LTS line. Version 43 uses full-width u32 indices with limit checks and is not susceptible to this bug.

The problem involves packed SSA value indices: silent overflow can produce incorrect intermediate-representation references and arbitrary miscompilation. A sufficiently large or specially constructed function can trigger type confusion or other effects that escape containment. Maintainers say default engines using Cranelift can be affected on any architecture or platform. The notice does not claim exploitation in the wild.

Find the runtime behind the application

Bulwark recommends treating this as an application-dependency investigation, not just a search for a standalone Wasmtime executable. For small businesses and government contractors, the practical exposure question is whether an application compiles or runs Wasm supplied by a less-trusted party.

  • Inventory the deployed engine. Ask application owners and suppliers which runtime, compiler backend and version their production build actually contains. Check dependency manifests, container contents and embedded components; a developer workstation's version does not establish server status.
  • Patch and redeploy. Move affected installations to 36.0.19 or a nonaffected release, following compatibility and supplier guidance. Rebuild applications that embed an affected dependency, then verify the version in the running artifact rather than stopping at a lockfile change.
  • Reduce untrusted execution while patching. Where feasible, pause submission paths for third-party Wasm or limit them to reviewed modules. Do not assume a different processor architecture removes the risk.
  • Review the host's privileges. Keep runtime processes away from unnecessary credentials, sensitive mounts and privileged service accounts. Separate tenants and workloads using independently enforced host controls; these are defense-in-depth measures, not substitutes for the compiler fix.
  • Preserve useful records. Retain available module-submission, build and execution logs. Investigate unexplained behavior under existing incident procedures, but do not label every crash or large module malicious.

Bulwark assessment

A sandbox is a security dependency, not an exemption from patch management. The priority is to identify where the runtime is embedded, close the vulnerable compilation path and limit what a compromised runtime process could reach. The severity warrants action without inventing an active campaign or claiming that every Wasm application is affected.

Original source

Wasmtime maintainer advisory GHSA-897f-g5gm-fmxm, published October 19, 2026.