WebAssembly's main selling point is the sandbox. You take code from someone you don't fully trust, compile it, and run it next to your own workloads, and the runtime keeps it inside its box. Two newly disclosed bugs in Wasmtime, the Bytecode Alliance's widely used WebAssembly runtime, undercut that promise. Both get a CVSS 3.1 score of 9.9 out of 10. In each case, a WebAssembly module written by an attacker can get the Cranelift compiler to produce wrong machine code, and the module can use that code to escape the sandbox.

The Bytecode Alliance published GitHub security advisories for CVE-2026-115889 and CVE-2026-115893. The National Vulnerability Database (NVD) added both records on October 23. According to The Hacker News, the fixed releases came out on October 19 and 20. As of October 26, neither flaw was in CISA's Known Exploited Vulnerabilities catalog, and none of the sources report exploitation in the wild.

Why a compiler bug becomes a sandbox escape

Wasmtime does not interpret WebAssembly one instruction at a time. Its Cranelift backend compiles each module into native machine code for the host CPU. The sandbox holds only if that compiled code does exactly what the WebAssembly specification allows: memory accesses stay within the module's own linear memory, and jumps go only to legitimate destinations.

If the compiler gets this wrong, the guarantees go with it. A miscompiled bounds check, a value read as the wrong type, or a branch that lands somewhere unintended can give a module access to host memory or code it was never supposed to reach. That is why both bugs carry a "Scope: Changed" rating in their CVSS vectors. The damage spreads past the component that has the bug and into the process hosting it.

CVE-2026-115889: an index overflow on every architecture

The first flaw is the broader of the two. According to the Bytecode Alliance advisory (GHSA-897f-g5gm-fmxm), Cranelift "bit-packs" its SSA value indices. These are the internal numbers the compiler uses to track every intermediate value in a function, and to save space Cranelift squeezed them into fewer bits than a full integer. In release builds, those packed indices can silently overflow. The result is miscompilation and type confusion: the compiler mixes up one value with another and generates code based on that mistake.

The advisory says a Wasmtime engine running with default settings, on any architecture can suffer a sandbox escape from a crafted module. It maps the flaw to CWE-197 (numeric truncation error) and CWE-843 (type confusion). The scoring vector is CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H. In plain terms, the attack is remote, low in complexity, and needs no user interaction. The attacker only needs the low privilege of getting a module compiled. The researcher credited with the report is jaydns.

Pay attention to the version numbers. The advisory says the bug is fixed in Wasmtime v36.0.19, and that Wasmtime v43 replaced the packed scheme with a full 32-bit index that has proper checks. The NVD record matches this: it lists the issue as affecting versions before 36.0.19 and before 43.0.0. Releases from 43.0.0 onward therefore do not contain this particular bug.

CVE-2026-115893: a giant jump table on ARM64

The second flaw is narrower in where it applies but just as serious. According to advisory GHSA-mghf-wjfp-p5xm, it affects only aarch64 (64-bit ARM) hosts using the Cranelift backend. It is triggered by a WebAssembly br_table instruction, which is essentially a switch statement that picks one of many branch targets based on an index. When a br_table has more than roughly 256,000 targets, Cranelift compiles it into a conditional branch that points at the wrong place. The advisory says this lets execution jump to arbitrary code at an offset the attacker controls, which amounts to a sandbox escape.

The bug has been around a long time. The advisory says every Wasmtime version that has supported aarch64 since 2020 is affected. Its affected ranges are everything below 36.0.19, versions 37.0.0 up to but not including 48.0.7, and versions 49.0.0 up to but not including 49.0.4. The patched releases are 36.0.19, 48.0.7 and 49.0.4. The Hacker News reports that Wasmtime 50.0.0, released October 20, fixes both CVEs. The researcher credited is ilyas-mallah.

The Hacker News also points out that ARM64 hosts patched in April for an earlier Cranelift sandbox escape are still exposed to CVE-2026-115893. Earlier patching does not cover this one, so check again.

Who should worry most

Both bugs need the same thing to be exploited: an attacker has to get a vulnerable Wasmtime build to compile a module the attacker controls. If your organization only runs WebAssembly that it wrote, built and signed itself, the practical risk is much lower than the 9.9 score implies.

The picture changes for any service whose purpose is to run other people's code. The Hacker News says the risk is highest for services that compile modules written by other people, and notes that Fastly says its Compute platform runs customer code using Wasmtime. Multi-tenant edge compute, plugin systems, serverless platforms, and applications that let users upload WebAssembly extensions all fit that description. The Hacker News notes that the advisories do not name any affected services or say what an attacker could access after escaping the sandbox, so the downstream impact on any one platform depends on how it isolates the runtime.

Supply chain is the less obvious exposure. Wasmtime can be built into other programs as a library, and The Hacker News stresses that updating the command-line tool does not fix those copies: each program that includes Wasmtime has to be rebuilt with a fixed version. You may be running it without knowing, inside software that bundles its own copy.

The support-window problem

According to The Hacker News, only the 36, 48, 49 and 50 release lines are currently supported. The 24.x long-term-support line reached end of life on August 20, 2026, and gets no fix. Anything still on 24.x, or on another unsupported line between 37 and 47, has to move to a supported release to be patched.

The sources don't fully agree on version details. The Hacker News's summary table lists 48.0.7, 49.0.4 and 50.0.0 as upgrade targets for the newer lines. The advisory and NVD text for CVE-2026-115889 say that bug only affects code before 43.0.0. The two are consistent once you see that 48.0.7 and 49.0.4 are required for the ARM64 br_table bug (CVE-2026-115893), not for the SSA-index bug. Where the sources differ, use the vendor advisories as the authority.

What It Means for Defenders

  • Inventory first. Find every place Wasmtime runs, including copies bundled as a library inside other products and services. Ask vendors whose platforms run WebAssembly whether they embed Wasmtime and which version they ship.
  • Upgrade to a fixed, supported release. Per the advisories and The Hacker News: 36.0.19 on the 36 line, 48.0.7 on the 48 line, 49.0.4 on the 49 line, or 50.0.0, which fixes both CVEs. Builds older than 36.0.19 are vulnerable to both bugs, and so is anything on the 24.x LTS line, which reached end of life on August 20 and will not be patched.
  • Prioritize ARM64 hosts. CVE-2026-115893 affects every aarch64-capable Wasmtime release since 2020, including hosts patched in April for the earlier Cranelift escape. Don't assume an ARM fleet is clean because it was patched recently.
  • Prioritize multi-tenant and plugin workloads. Systems that compile WebAssembly from customers, users or third parties are where an attacker-supplied module is realistic. Patch those before internal-only deployments.
  • Know that there is no workaround. The Hacker News says neither advisory lists one. Until a host is updated, the risk comes from any module an outsider can supply, so limiting who can submit modules to trusted parties is a reasonable stopgap, but it is not a substitute for the update.
  • Keep defense in depth around the runtime. Wasmtime's sandbox should not be the only layer between untrusted code and sensitive data. OS-level isolation, least-privilege service accounts and network segmentation limit what a successful escape can reach.
  • For CMMC and compliance programs: document the affected assets, the remediation date and any compensating controls. A CVSS 9.9 flaw in a component that runs untrusted code is the kind of finding assessors expect to see tracked through to closure.

Neither flaw was in CISA's KEV catalog as of October 26, and the sources report no exploitation. Don't count on that lasting. A sandbox escape in a compiler that runs untrusted code on shared infrastructure is a high-value target, and both bugs are now public along with their patches.

Sources