Two critical Wasmtime flaws could let hostile WebAssembly modules escape their sandbox
Services running third-party WebAssembly code must rebuild against fixed releases, since no fix exists for the 24.x line.
Two critical Wasmtime flaws, both rated 9.9 out of 10 on CVSS, could let a hostile WebAssembly module break out of its sandbox, according to the Bytecode Alliance maintainers. The first, CVE-2026-115889, affects all architectures and stems from Cranelift packing value-tracking numbers into 24-bit fields that overflow silently in release builds, while the second, CVE-2026-115893, affects only ARM64 because out-of-range br_table jumps can be sent to the wrong place once a jump table grows past roughly 256,000 targets. Fixed releases arrived on October 19 and 20 in 36.0.19, 48.0.7, 49.0.4 and 50.0.0, and the maintainers report no exploitation. Because Wasmtime is embedded as a library, each application that links it must be rebuilt rather than just updating the CLI, and hosts on unsupported lines such as 24.x have no fix. Services that run third-party WebAssembly code are most exposed, and neither flaw had appeared in CISA's known-exploited catalogue as of October 26.
Why it matters
Any service that runs untrusted WebAssembly inside a Wasmtime-based host is the group most exposed, because a sandbox escape would let untrusted code reach beyond its containment. Each affected application has to be rebuilt with a patched version rather than relying on a CLI update, and hosts still on the 24.x line have no patch at all, so they remain open until they move to a supported release.
Matters or hype?
Does this story matter, or is it hype? Vote before you see what everyone else said.