As reported by The Hacker News, the Bytecode Alliance has disclosed two critical vulnerabilities in Wasmtime, the widely-adopted WebAssembly runtime, that fundamentally undermine its core security promise: sandbox isolation. Both flaws reside in Cranelift, the default compiler that translates WebAssembly bytecode into native machine code, and carry a CVSS score of 9.9 — about as severe as it gets.
Why This Matters Beyond the CVE Numbers
WebAssembly has moved far beyond its browser origins. It now powers serverless compute platforms, edge networking services, plugin systems, and increasingly, AI model sandboxes. The entire trust model rests on the assumption that a WebAssembly module cannot touch host memory, call arbitrary host functions, or execute outside its bounds. Both CVE-2026-115889 and CVE-2026-115893 break that assumption.
The practical impact is architecture-dependent but architecturally significant: a malicious module, once compiled by a vulnerable Wasmtime build, can escape the sandbox and potentially execute arbitrary code in the host process context. For multi-tenant platforms that compile and run customer-supplied code — the Fastly Compute model, edge CDN functions, serverless FaaS providers — this is a cross-tenant compromise scenario.
Vulnerability Summary
| Attribute | CVE-2026-115889 | CVE-2026-115893 |
|---|---|---|
| CVSS | 9.9 (Critical) | 9.9 (Critical) |
| Component | Cranelift compiler | Cranelift compiler |
| Architecture | All | ARM64 / aarch64 only |
| Prerequisite | Attacker-controlled module compiled by vulnerable Wasmtime | Same |
| Patch Available | Yes — fixed in 36.0.19, 48.0.7, 49.0.4, 50.0.0 | Yes — same releases |
| Active Exploitation | None reported as of Oct 26, 2026 | None reported |
| CISA KEV | Not listed | Not listed |
Who Is Actually at Risk
The threat model narrows the exposed population considerably. Single-tenant deployments that only compile their own internal WebAssembly modules face minimal real-world risk — the attacker would need code execution capability to supply a malicious module, making this a privilege escalation vector rather than an initial access tool.
The high-risk population includes:
The ARM64-specific nature of CVE-2026-115893 deserves particular attention: edge computing and IoT-adjacent workloads — precisely the deployments most likely to run on ARM64 — are disproportionately exposed to the second flaw.
Shield53 Recommendations
- Immediate patching: Upgrade to 36.0.19, 48.0.7, 49.0.4, or 50.0.0 depending on your release line. If you are on 24.x or any unsupported line, migrate to a supported release now — no backport exists.
- Audit your supply chain: Identify all embedded Wasmtime instances, including those bundled inside serverless frameworks, CDN tooling, or container runtimes. Embedded copies are the easiest to miss.
- Architecture review: For ARM64 deployments, verify both CVEs are addressed — the all-architecture fix alone does not cover CVE-2026-115893.
- Defense in depth: If your platform compiles untrusted modules, consider additional isolation layers — seccomp profiles, namespace isolation, or running Wasmtime inside a container — so that a sandbox escape does not immediately yield host access.
- Detection: Monitor for abnormal syscalls or process behavior from Wasmtime-host processes. Sandbox escapes typically manifest as host system calls that should never originate from a WASM module.
- Deprioritize single-tenant deployments: If your Wasmtime instances only compile internally-authored modules, this is a lower priority — but still patch on your normal cadence.
The broader lesson here is that the WebAssembly security model remains strong in theory but dependent on compiler correctness in practice. Cranelift is a complex JIT and that complexity is where sandbox boundaries fracture. Organizations building trust on WASM isolation should treat compiler-level vulnerabilities as a permanent threat category, not an anomaly.
