Two critical Wasmtime Cranelift flaws (CVE-2026-115889, CVE-2026-115893) allow WebAssembly sandbox escape
The Bytecode Alliance disclosed two critical flaws (CVSS 9.9) in Cranelift, the default compiler in the Wasmtime WebAssembly runtime. A malicious WebAssembly module could use them to escape its sandbox. CVE-2026-115889 affects all architectures, while CVE-2026-115893 affects only ARM64 (aarch64). Fixes shipped on October 19 and 20, and the maintainers have reported no attacks. Neither flaw was in CISA's KEV catalog as of October 26. The risk is highest for services that compile modules written by third parties, such as Fastly Compute, which runs customer code on Wasmtime.
Entenda a falha
A vulnerabilidade
Two critical flaws (CVSS 9.9) in Cranelift, the default compiler of the Wasmtime WebAssembly runtime, let a malicious Wasm module escape its sandbox. The attacker must get a vulnerable Wasmtime build to compile a module they control. CVE-2026-115889 affects all architectures; CVE-2026-115893 affects only ARM64 (aarch64) with default settings. Fixed versions are 36.0.19, 48.0.7, 49.0.4 and 50.0.0 (October 20). Only the 36, 48, 49 and 50 lines are supported; others, including 24.x LTS, got no fix. ARM64 hosts that moved to 36.0.7, 42.0.2 or 43.0.1 in April for an earlier escape are still affected by CVE-2026-115893.
Como funciona
Wasmtime receives a Wasm module and Cranelift compiles it to machine code, which is meant to stay inside the module's own memory, the host functions it is given and checked jump targets. For CVE-2026-115889, Cranelift tracks values in a function with numbers packed into 24-bit fields. In a very large function, or one crafted to use many values, a number overflows its field silently in release builds, so Cranelift refers to the wrong value and emits wrong code, causing type confusion. For CVE-2026-115893, a br_table sends out-of-range indexes to a default target on ARM64 through a branch reaching about 1 MiB. With more than about 256,000 targets the jump table grows past that reach and the branch silently lands in the wrong place.
Por que é vulnerável
CVE-2026-115889 is an unchecked integer overflow: value numbers were stored in 24-bit fields and, in release builds, overflow produced no error. CVE-2026-115893 is a wrong assumption that a short-range ARM64 branch could always reach the default target, however large the br_table. It has existed since ARM64 support arrived in 2020. The first flaw went unrecognized because the change widening the fields to 32 bits (merged February 18, shipped in 43.0.0 on March 20) was described as enabling larger functions, not as a security fix. The fix for the second sends out-of-range indexes through the jump table itself, and fixed versions refuse to compile a br_table with more than 65,520 targets.
Onde está
The articles name no file, function or commit; they place the flaws in Cranelift's handling of value numbers (CVE-2026-115889) and its ARM64 br_table lowering (CVE-2026-115893), tracked as RUSTSEC-2026-0380 and RUSTSEC-2026-0379.
Como foi descoberta
The articles do not say who found the flaws or how. The Bytecode Alliance, Wasmtime's maintainers, published advisories on October 19 and shipped fixes on October 19 and 20. They report no attacks, and neither CVE was in CISA's KEV catalog as of October 26. The advisory does not say when the security impact of the 24-bit field problem was recognized, though the widening change had landed in the main line months earlier without a security label. RustSec lists both flaws, but GitHub's database had a reviewed entry only for CVE-2026-115889.
Explicação gerada por IA a partir da matéria e dos artigos, em 26/10/2026 12:16.
Detalhes técnicos
- CVE-2026-115889: before version 43, Cranelift packed value numbers into 24-bit fields. In release builds, a number too large for its field overflowed silently, so Cranelift referred to the wrong value and emitted incorrect machine code. A very large function, or one crafted to use many values, can force type confusion and a sandbox escape. Wasmtime 43.0.0 (March 20) had already widened the fields to 32 bits, but the change was described as a way to compile larger functions, not as a security fix. The 36.x LTS line received the same change on October 19.
- CVE-2026-115893: on ARM64, Cranelift sent out-of-range
br_tableindexes to the default target with a branch that reaches only about 1 MiB. Abr_tablewith more than about 256,000 targets made the jump table too large, so the branch silently pointed to the wrong place. A user-controlled Wasm module can force a jump to arbitrary code on any default-configured ARM64 engine. The bug has existed since ARM64 support was added in 2020. Hosts that updated to 36.0.7, 42.0.2 or 43.0.1 in April for an earlier ARM64 sandbox escape are still affected. - The advisories do not name affected services or say what an attacker could access after escaping.
- Both flaws are tracked in RustSec as RUSTSEC-2026-0380 and RUSTSEC-2026-0379. GitHub's advisory database had a reviewed entry only for CVE-2026-115889 as of October 26, so Dependabot will not alert on the ARM64 flaw.
Remediação
- Update to 36.0.19, 48.0.7 or 49.0.4, or to Wasmtime 50.0.0 (October 20), which fixes both flaws.
- Only the 36, 48, 49 and 50 lines are supported. Unsupported lines, including 24.x LTS (support ended August 20, 2026), received no fix and must migrate.
- Wasmtime is often embedded as a library, so updating the CLI is not enough. Every program that embeds it must be rebuilt with a fixed version.
- No workaround exists. Until hosts are updated, restrict who can supply modules.
- Spin moved to Wasmtime 50.0.0 in version 4.2.4 on October 21.
- Fixed versions refuse to compile a
br_tablewith more than 65,520 targets.
Linha do tempo
-
Two critical Wasmtime Cranelift flaws (CVE-2026-115889, CVE-2026-115893) allow WebAssembly sandbox escape
ler a análise desta fonte ocultar
The Bytecode Alliance disclosed two critical flaws (CVSS 9.9) in Cranelift, the default compiler in the Wasmtime WebAssembly runtime. A malicious WebAssembly module could use them to escape its sandbox. CVE-2026-115889 affects all architectures, while CVE-2026-115893 affects only ARM64 (aarch64). Fixes shipped on October 19 and 20, and the maintainers have reported no attacks. Neither flaw was in CISA's KEV catalog as of October 26. The risk is highest for services that compile modules written by third parties, such as Fastly Compute, which runs customer code on Wasmtime.
Technical Details
- CVE-2026-115889: before version 43, Cranelift packed value numbers into 24-bit fields. In release builds, a number too large for its field overflowed silently, so Cranelift referred to the wrong value and emitted incorrect machine code. A very large function, or one crafted to use many values, can force type confusion and a sandbox escape. Wasmtime 43.0.0 (March 20) had already widened the fields to 32 bits, but the change was described as a way to compile larger functions, not as a security fix. The 36.x LTS line received the same change on October 19.
- CVE-2026-115893: on ARM64, Cranelift sent out-of-range
br_tableindexes to the default target with a branch that reaches only about 1 MiB. Abr_tablewith more than about 256,000 targets made the jump table too large, so the branch silently pointed to the wrong place. A user-controlled Wasm module can force a jump to arbitrary code on any default-configured ARM64 engine. The bug has existed since ARM64 support was added in 2020. Hosts that updated to 36.0.7, 42.0.2 or 43.0.1 in April for an earlier ARM64 sandbox escape are still affected. - The advisories do not name affected services or say what an attacker could access after escaping.
- Both flaws are tracked in RustSec as RUSTSEC-2026-0380 and RUSTSEC-2026-0379. GitHub's advisory database had a reviewed entry only for CVE-2026-115889 as of October 26, so Dependabot will not alert on the ARM64 flaw.
Remediation
- Update to 36.0.19, 48.0.7 or 49.0.4, or to Wasmtime 50.0.0 (October 20), which fixes both flaws.
- Only the 36, 48, 49 and 50 lines are supported. Unsupported lines, including 24.x LTS (support ended August 20, 2026), received no fix and must migrate.
- Wasmtime is often embedded as a library, so updating the CLI is not enough. Every program that embeds it must be rebuilt with a fixed version.
- No workaround exists. Until hosts are updated, restrict who can supply modules.
- Spin moved to Wasmtime 50.0.0 in version 4.2.4 on October 21.
- Fixed versions refuse to compile a
br_tablewith more than 65,520 targets.