Wasmtime Runtime CVEs

WebAssembly is the part that lets developers run compact, sandboxed code outside a browser, and Wasmtime is one of the runtimes that does the heavy lifting by turning that code into native machine instructions on the host computer. On April 9, 2026, the Bytecode Alliance shipped emergency Wasmtime patches 24.0.7, 36.0.7, 42.0.2, and 43.0.1 after disclosing 12 separate security advisories in one batch. (bytecodealliance.org) A runtime is supposed to be the security guard between guest code and host memory, the way an apartment wall separates one tenant from the next. In this release, the Wasmtime maintainers said 2 of the 12 advisories were rated Critical, and they told users to upgrade “as soon as possible.” (bytecodealliance.org) One bug sat in `wasmtime::Linker`, which is the part embedders use to wire guest code to host functions like plugging labeled cables into a patch panel. In Wasmtime 43.0.0, cloning that linker and then dropping the original could leave the clone pointing at freed memory, which GitHub’s advisory says can crash with a segmentation fault. (github.com) That linker flaw was narrow, because the Wasmtime team says guest WebAssembly code could not trigger it directly and command-line users were not affected. The affected path was host code using the embedding application programming interface and calling the linker’s clone operation, and the fix landed in 43.0.1. (github.com) Another bug hit the pooling allocator, which is the memory-reuse system that keeps a row of prebuilt slots ready so new WebAssembly instances start fast. In affected configurations, Wasmtime could reuse a slot without correctly resetting linear memory protections, which meant one instance could see leftover bytes from a previous instance. (github.com) A different flaw lived in Winch, which is Wasmtime’s baseline compiler and not the default Cranelift compiler. GitHub’s advisory says Winch miscompiled the `table.size` instruction for 64-bit tables in the WebAssembly memory64 feature, and that mistake could leak data from the host stack back into guest code. (github.com) That Winch bug did not hit every Wasmtime deployment, because the advisory says Cranelift users were not affected. The exposure was limited to setups using Winch with the memory64 proposal enabled, and the published workaround was to disable `Config::wasm_memory64` if an upgrade could not happen immediately. (github.com) String transcoding was another trouble spot, and that is the code that converts text between formats the way a travel adapter converts one plug shape into another. One April 9 advisory says Wasmtime could pass misaligned pointers while converting Component Model strings into UTF-16 or latin1-plus-UTF-16, which let a malicious guest trigger a host panic and denial of service. (github.com) A related string bug checked the length of UTF-16 input in code units instead of bytes, which is like counting 10 boxes when the truck actually needs room for 20. Public CVE records for CVE-2026-34941 say that mistake could read past the end of WebAssembly linear memory during transcoding to the Component Model’s latin1-plus-UTF-16 format. (tenable.com) The surprising part of this release is how the bugs were found. The Bytecode Alliance says 11 of the 12 advisories came from new large language model based tooling used during a three-week sprint by engineers from Mozilla, the University of California San Diego, Akamai, and F5. (bytecodealliance.org) Wasmtime is written in Rust, uses continuous fuzzing, and says its Cranelift code generator has formal verification, but April 9 still produced the project’s biggest single advisory batch ever. If your stack uses WebAssembly for frontend acceleration, edge compute, plugins, or server-side isolation, the practical version is simple: runtime updates now belong on the same checklist as browser patches and operating system patches. (bytecodealliance.org)