Wasmtime runs WebAssembly code outside a browser. WebAssembly is a portable code format. Services use it to run code from other parties in a sandbox.

Which versions are fixed?

Line 36 is fixed at 36.0.19. Line 43 fixed the first flaw at 43.0.0. Lines 48 and 49 fixed the second flaw at 48.0.7 and 49.0.4. Line 50 includes both fixes.

Is there active exploitation?

No attacks are reported as of October 26, 2026. Neither flaw is in the list kept by the Cybersecurity and Infrastructure Security Agency (CISA) as of that date.

ResourcesBlog

Two Wasmtime Flaws Break the Sandbox Promise

Two flaws score 9.9. Each lets a crafted module escape its sandbox. The fix is a version check, not a new tool.

Leonard EserePublished 2026-10-27Reading time 5 min

Filed underWasmtime sandbox escape flaw remediation supply chain evidence

Two Wasmtime Flaws Break the Sandbox Promise

Summary

Two flaws score 9.9. Both sit in the compiler that turns modules into machine code.
One flaw hits every chip type. One flaw hits only ARM64 hosts.
Fixed versions vary by release line, from 36.0.19 to 50.0.0.
A sandbox escape breaks the proof behind any control that trusts isolation.

The sandbox is the whole promise

WebAssembly promises safe execution of code you do not trust. A module should stay inside its own memory. It should call only the host functions it was given. Wasmtime is a runtime that runs WebAssembly (Wasm) code outside a browser. Cranelift is the compiler Wasmtime uses by default. It turns Wasm modules into machine code for the host chip. If that machine code is wrong, the sandbox promise fails.

Two flaws, one broken promise

The maintainers rated both flaws 9.9 on the Common Vulnerability Scoring System (CVSS). That score is near the top of the scale. CVE-2026-115889 hits every architecture that uses the default compiler. Cranelift packs its static single assignment (SSA) value numbers into small fields. In release builds, a large number can overflow its field with no error. Cranelift then points at the wrong value. The wrong value means wrong machine code. Wrong machine code can mix up types and escape the sandbox. The flaw is fixed in 36.0.19 and 43.0.0.

CVE-2026-115893 hits only ARM64 hosts, also called aarch64. It involves br_table, a Wasm instruction that jumps to one of many targets. On ARM64, a table with more than about 256,000 targets breaks the default branch. The branch then lands in the wrong place. A module the attacker controls can force that jump. The flaw is fixed in 36.0.19, 48.0.7, and 49.0.4. Both flaws need only a module the attacker controls. No user action is needed.

Who faces the most risk

Risk is highest for services that compile modules from other parties. That includes cloud platforms, serverless tools, and developer tools. Those services compile code they did not write. If a service compiles only its own code, risk is lower. Lower risk is not zero risk. Old builds can linger in libraries and bundled tools. A version check must cover libraries, not just the command line tool.

What to prove after patch day

Fixed versions depend on your release line. Line 36 needs 36.0.19 or later in that line. Lines 43 through 47 need a move to a fixed later line for the second flaw. Line 48 needs 48.0.7. Line 49 needs 49.0.4. Rebuild every app that embeds Wasmtime as a library. Updating the command line tool alone leaves library copies behind. The proof set is the old version, the new version, the rebuild date, and the scan result. That record is the proof an assessor will ask for.

The governance lesson

A sandbox is a control, not a slogan. Teams trust it when they run code from other parties. When the compiler breaks, that trust breaks with it. Evidence must name the runtime version, not just the app version. PolicyCortex collects evidence from live configuration and ties each control to the setting that met it. That habit is what this story demands. The lesson is simple: know what runs, prove the version, and keep the record.

Ask your team for the Wasmtime version list this week.

Sources

CVE-2026-115889 record, CVE Program.
CVE-2026-115893 record, CVE Program.
Wasmtime advisory GHSA-897f-g5gm-fmxm, Bytecode Alliance. https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-897f-g5gm-fmxm
Wasmtime advisory GHSA-mghf-wjfp-p5xm, Bytecode Alliance. https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-mghf-wjfp-p5xm
Two Critical Wasmtime Flaws Could Let Malicious WebAssembly Modules Escape Sandboxes, The Hacker News, October 2026. http://thehackernews.com/2026/10/two-critical-wasmtime-flaws-could-let.html
Original diagram by PolicyCortex.

Questions on this record

What is Wasmtime?: Wasmtime runs WebAssembly code outside a browser. WebAssembly is a portable code format. Services use it to run code from other parties in a sandbox.
Which versions are fixed?: Line 36 is fixed at 36.0.19. Line 43 fixed the first flaw at 43.0.0. Lines 48 and 49 fixed the second flaw at 48.0.7 and 49.0.4. Line 50 includes both fixes.
Is there active exploitation?: No attacks are reported as of October 26, 2026. Neither flaw is in the list kept by the Cybersecurity and Infrastructure Security Agency (CISA) as of that date.

Related records

Guides and articles describe the work. The evidence that work produces is described in three proof pages and one architecture page.

proof.state: Proof of State. What the environment was, as of a date someone else picks: point-in-time records, content hashed and chained.
proof.change: Proof of Change. Who or what altered the environment, under what authority, with before and after state hashes.
proof.agency: Proof of Agency. What a machine was permitted to do before it acted, what it did, and what would have stopped it.
architecture: Architecture. How the chain is built and where it lives: inside your tenant, with no egress of evidence.