Vulnerabilities · Application Security
Critical Wasmtime flaws let malicious WebAssembly modules escape sandbox
Two critical bugs in Wasmtime could let attacker-controlled WebAssembly modules break out of their sandbox. Patches are available, but only for supported versions and affected programs must be rebuilt.
Ross Grant3 min read
The short version
Wasmtime is software that lets other programs run WebAssembly code. Two serious bugs in Wasmtime could let a malicious module break out of its safe area, which is supposed to keep it from interfering with the rest of the system. The maintainers have released patches, but only for supported versions. Anyone using Wasmtime to run code from others should update and rebuild their software as soon as possible.
What happened?
Two critical bugs in Wasmtime, a WebAssembly runtime, could let attacker-controlled modules escape the sandbox. The flaws, in the Cranelift compiler, were fixed on 19 and 20 October 2026. Only supported versions are patched, and each affected program must be rebuilt. There are no reports of attacks so far, and only one outlet has reported the story.
How the flaw works
Two critical vulnerabilities in Wasmtime, a popular WebAssembly runtime, could let a malicious WebAssembly module escape the sandbox that is supposed to contain it. Wasmtime is used to run WebAssembly code outside web browsers and is often built into other software. The sandbox is meant to keep each module isolated, restricting it to its own memory and approved host functions.
Both flaws are in Cranelift, the compiler Wasmtime uses to turn WebAssembly into machine code. The project's maintainers at the Bytecode Alliance rated both flaws 9.9 out of 10 on the CVSS scale. One flaw (CVE-2026-115889) affects all processor architectures. The other (CVE-2026-115893) only affects ARM64 systems, also called aarch64. According to the maintainers, an attacker would need to get a vulnerable Wasmtime build to compile a module they control. This risk is highest for services that run untrusted user code, such as cloud platforms.
CVE-2026-115889 is caused by how Cranelift stored internal numbers in 24-bit fields. If a function used too many values, the numbers could overflow, causing Cranelift to reference the wrong value and generate incorrect machine code. This could allow a carefully crafted module to escape the sandbox. The fix, which widened these fields to 32 bits, was quietly included in Wasmtime 43.0.0 in March 2026, but only later recognised as a security issue.
CVE-2026-115893 involves the WebAssembly br_table instruction, which jumps to different code locations. On ARM64, if a jump table was too large, Cranelift could send execution to the wrong place, letting a malicious module jump to arbitrary code. This bug has existed since ARM64 support was added in 2020.
Who is affected
Any software that embeds Wasmtime and allows users to supply their own WebAssembly modules could be at risk, especially if it is running on ARM64 hardware. The risk is highest for platforms that run untrusted code, such as Fastly's Compute platform. The advisories do not list specific affected services or what data could be accessed after a sandbox escape. Hosts that updated to certain earlier versions to fix a previous ARM64 bug are still vulnerable to CVE-2026-115893.
Is there a fix?
Patches for both flaws were released on 19 and 20 October 2026. Supported release lines (36, 48, 49, and 50) have fixed versions: 36.0.19, 48.0.7, 49.0.4, and 50.0.0. Older versions, including the 24.x LTS line, are no longer supported and did not get a fix. Each application that includes Wasmtime must be rebuilt with a fixed version; updating the command-line tool alone is not enough. There are no listed workarounds. Until updated, any host that compiles outsider-supplied modules is at risk.
The response
The Bytecode Alliance published advisories on 19 October. Both flaws are now listed in RustSec, the Rust security advisory database, as RUSTSEC-2026-0380 and RUSTSEC-2026-0379. GitHub's advisory database has a reviewed entry for CVE-2026-115889, which means Dependabot users can get alerts for that flaw, but not yet for CVE-2026-115893. Spin, an open-source tool for serverless WebAssembly apps, moved to Wasmtime 50.0.0 on 21 October. As of 26 October, there are no reports of attacks exploiting these flaws, and neither appears in the US CISA's Known Exploited Vulnerabilities catalogue. The Hacker News (opens in a new tab) is the only outlet to have reported these issues so far.
Why it matters
If a malicious module escapes the Wasmtime sandbox, it could run code or access data outside its intended limits. This is especially risky for cloud services that run code from many users. Updating to a fixed version is essential to prevent possible attacks.
Key points
- Two critical Wasmtime bugs could let attacker-controlled modules escape the sandbox.
- One flaw affects all systems, the other only ARM64 (aarch64).
- Patches are available for supported versions; each affected program must be rebuilt.
- No attacks have been reported so far, and only one outlet has covered the story.
- Cloud services running untrusted code are most at risk.
Sources
The Hacker News
Reference