On this page (7 sections)
Wasmtime, the Bytecode Alliance's WebAssembly runtime, has a critical flaw in its Cranelift compiler backend. According to the GitHub advisory, a very large or specially crafted Wasm function can trigger a silent integer overflow during compilation, leading to miscompiled code and a possible escape from the Wasm sandbox.
If your site, platform or service runs untrusted or customer-supplied WebAssembly through Wasmtime, this is worth patching now. If you only run Wasm modules you wrote and fully control, your exposure is much lower, but updating is still the right move.
What happened
The Wasmtime maintainers published an advisory on October 19, 2026, which GitHub reviewed and updated on October 23, 2026. The issue was credited to a reporter named jaydns. At the time of writing, only the advisory itself covers the story, so there is no independent analysis to cross-check, and the details below come from that single primary source.
The advisory states that Cranelift, the compiler Wasmtime uses by default to turn WebAssembly into machine code, packs its SSA value indices into a compact bit layout. In release builds that packing can overflow without any error.
Technical details in plain terms
When a compiler translates a function, it gives every intermediate value an index so later steps can refer to it. If the index is squeezed into too few bits, a function with enough values can wrap around, and the compiler then points at the wrong value. Because the overflow is silent in release builds, nothing warns you.
The advisory says the result is arbitrary miscompilation: generated code that does not match what the Wasm module actually says. It describes type confusion and other attacker-controlled effects that can escape the sandbox. Type confusion means the program treats a piece of memory as one kind of data when it is really another, which is a common route from a memory-safety bug to code running outside its intended boundary.
The trigger is a very large Wasm function body, or one crafted to use many SSA values. The advisory says a Wasmtime engine with default settings, using the Cranelift backend, on any architecture or platform could be affected. The fix in Wasmtime 43 changes Cranelift to use a full u32 index and adds checks if that limit is exceeded.
The CVSS vector reflects this: network attack vector, low complexity, low privileges, no user interaction, and a changed scope because the impact crosses the sandbox boundary. The GitHub advisory also lists an EPSS score of 0.454% (39th percentile), an estimate of exploitation likelihood over 30 days, not a confirmation either way.
Who is affected
The realistic exposure depends on where the Wasm comes from:
- Platforms that accept user-uploaded or third-party Wasm modules (plugin systems, edge functions, serverless runtimes, extension marketplaces) are the highest-risk group, since an attacker only needs to submit a module.
- Applications that embed Wasmtime as a Rust dependency inherit the flaw until they rebuild against a fixed version.
- Teams that run only trusted, internally built Wasm have lower risk, though a compromised build pipeline or dependency could still deliver a malicious module.
- Wasmtime 37.x up to 42.x is affected, as are all versions below 36.0.19. The advisory lists no affected range between 36.0.19 and 37.0.0 beyond those two patched lines, so check your exact version rather than assuming.
How to check your exposure
Start by finding every place Wasmtime is used: standalone CLI installs, container images, and Rust projects that depend on the wasmtime crate. The first command prints the version of an installed Wasmtime CLI; compare it to the affected ranges above.
wasmtime --versionFor a Rust project, the next command lists which wasmtime version your lockfile resolves, including transitive dependencies. Run it in the project directory and look for a version below 36.0.19, or from 37.0.0 up to below 43.0.0.
cargo tree -i wasmtimeRemember that container images and prebuilt binaries bundle their own copy. Check the version inside each image, and ask vendors of any product embedding Wasmtime which version they ship.
What to do now
The fix is to move to a patched release. The advisory names 36.0.19 for the 36.x line and 43.0.0 for newer versions. If you are on 37.x through 42.x, the listed fix is 43.0.0, so plan for a major version upgrade and test your embedding code against it.
This command updates the dependency in a Rust project to the newest compatible version allowed by your Cargo.toml. If your version requirement pins an older major release, edit it to allow 43.0.0 or 36.0.19 first, then rebuild.
cargo update -p wasmtime0 of 7 done
Detection and monitoring
The advisory reports no known exploitation and gives no indicators of compromise, so there is no signature to hunt for. Practical monitoring is about reducing blast radius and spotting oddities:
- Log which modules are loaded, who submitted them, and their size, so unusually large or generated functions stand out.
- Watch the processes hosting Wasmtime for unexpected child processes, outbound connections or file access.
- Track the Wasmtime version in your dependency and image scanning so a future advisory is caught quickly. A software composition scan or advisory feed for the Rust ecosystem lists this issue as RUSTSEC-2026-0380.
If your product exposes a public web front end that sits in front of a Wasm runtime, regular outside-in checks are a useful extra layer, for example the free security headers checker or ongoing monitoring. They do not detect or fix this runtime flaw; patching does.
Timeline
| Date | Event |
|---|---|
| Oct 19, 2026 | Advisory published in the bytecodealliance/wasmtime repository |
| Oct 23, 2026 | Published to the GitHub Advisory Database, reviewed and last updated |
| Oct 23, 2026 | CVE record published with CVSS 9.9 |
Fix details are in the v36.0.19 release and v43.0.0 release, and the maintainers' security advisory. For broader habits around keeping dependencies current, see our small business website security guide.
Sources
This article is based on the public sources below. Details can change as vendors and researchers publish more; check the original advisories before acting on version numbers.