Wasmtime security advisory warns of memory64 table overflow crash risk

A moderate-severity Wasmtime advisory published April 30 warned that a table-allocation path can overflow and panic when a module or component asks for an extremely large WebAssembly table, turning a bad guest into a host crash.

The bug matters because Wasmtime runs untrusted code by design. In the default on-demand instance allocator, checked arithmetic in table allocation could wrap in the memory64 world, where table sizes reach 64-bit territory instead of the older 32-bit ceiling. A hostile or malformed guest that triggers that path can take down the host process, which is exactly the kind of denial-of-service failure embedders try to keep out of a sandbox.

Alex Crichton authored the advisory, which rates the issue Moderate with a 5.9 CVSS score. The affected range is wide: 30.0.0 through 36.0.7, 37.0.0 through 43.0.1, and 44.0.0. Wasmtime 36.0.8, 43.0.2, and 44.0.1 carry the fix.

The good news is that not every deployment is exposed. The pooling allocator is not affected because it caps table sizes well below the threshold needed to trigger the overflow. The advisory says memory64 is on by default, so any embedder relying on the default allocator and accepting attacker-controlled modules or components should treat this as an immediate update item. If you are still on a vulnerable branch, switching to the pooling allocator or disabling memory64 can blunt the risk, but the clean answer is to move to a patched release.

This is a reminder that Rust memory safety is not the same as bug immunity. The overflow is not a use-after-free or a data race; it is a higher-level logic failure in a runtime that has to defend itself against adversarial inputs. Once memory64 expanded the table space, Wasmtime’s arithmetic assumptions had more room to fail, and the panic became reachable in production paths that many embedders would consider routine.

The fix also fits a broader hardening pattern inside the Bytecode Alliance. Wasmtime added support for the memory64 table64 extension in v26.0 on October 25, 2024, became the Bytecode Alliance’s first Core Project on April 30, 2025, and the project’s release process now ships major versions on the 20th of each month, with every 12th release treated as an LTS build supported for 24 months. On April 9, 2026, the Bytecode Alliance said Wasmtime had already shipped fixes for 12 security advisories in a three-week sprint, 11 of them found with new LLM-based tools and with help from Mozilla, the University of California, San Diego, Akamai, and F5. That’s the backdrop here: a runtime built for hostile code, and a bug that shows how quickly a single unchecked edge can turn into an outage.