Tech Infrastructure

Tech Infrastructure Alert: Two Flaws Break Wasm Sandboxes

By Nattapong Sukkasem · Published 2026-10-27 · Updated 2026-10-27.

TL;DR — The Bytecode Alliance published two Wasmtime advisories on 19 October, both rated CVSS 9.9, and both in Cranelift, the compiler that turns WebAssembly into machine code. A crafted module can escape the sandbox. CVE-2026-115889 affects every architecture; CVE-2026-115893 affects only aarch64 and has been present since Arm support shipped in 2020. Wasmtime 50.0.0 fixes both. No exploitation has been reported. For any tech infrastructure that compiles code supplied by somebody else, the interesting part is where the boundary turned out to live.

A WebAssembly sandbox is not a wall. It is a claim made by a compiler — that the machine code it just emitted cannot read, write or jump outside the region it was handed. WebAssembly enforces its boundary at compile time, by generating code that cannot misbehave. That is the design, and it is why Wasm became attractive tech infrastructure for running untrusted modules at density. Two advisories published on 19 October are a reminder of the corollary: when the boundary is emitted rather than imposed, a compiler bug is an isolation bug.

Tech infrastructure news: the Arm headquarters building in Cambridge, England, whose aarch64 architecture is the only one affected by the Wasmtime Cranelift br_table sandbox escape — Arm's Cambridge headquarters. One of the two flaws is specific to aarch64, the architecture that now carries a large share of cloud and edge **server infrastructure**.

Two bugs, one compiler

CVE-2026-115889 is a counting problem. Before Wasmtime 43, Cranelift packed the indices it uses to track values inside a function into 24-bit fields. In release builds an index too large for its field overflowed silently — no panic, no error, just a number that wrapped. Cranelift could then reference the wrong value and emit machine code for an operation it never meant to compile. The advisory describes the outcome as arbitrary miscompilation, classified as both numeric truncation (CWE-197) and type confusion (CWE-843).

The aarch64 flaw, CVE-2026-115893, is a reach problem. WebAssembly's br_table instruction jumps to one of many targets selected by an index, with out-of-range indices going to a default target. On aarch64, Cranelift routed that default case through a conditional branch that can only reach about one mebibyte. Give the instruction more than roughly 256,000 targets and the jump table outgrows that reach, so the branch quietly lands somewhere else. The advisory's own phrasing is that an engine on aarch64 with default settings can be forced to jump to arbitrary code at a user-controlled offset. The fix, merged as PR 14826, routes out-of-range indices through the jump table so no long branch is needed, and additionally rejects any br_table with more than 65,520 targets.

Wasmtime line	115889 (all arch)	115893 (aarch64)	Action
Below 36.0.19, incl. 24.x LTS	Affected	Affected	Update to 36.0.19 or later; 24.x is end-of-life and unpatched
37.0.0 – 42.x	Affected	Affected	Move to 48.0.7, 49.0.4 or 50.0.0
43.0.0 – 47.x	Not affected	Affected	Move to 48.0.7, 49.0.4 or 50.0.0
48.0.0 – 48.0.6	Not affected	Affected	Update to 48.0.7
49.0.0 – 49.0.3	Not affected	Affected	Update to 49.0.4
36.0.19, 48.0.7, 49.0.4, 50.0.0+	Fixed	Fixed	None

Neither flaw is a zero-day vulnerability in the sense that matters operationally. Both were patched before anyone reported an attack, and the all-architecture bug was fixed in March, in Wasmtime 43.0.0, by a change that widened the fields to a full 32-bit index with limit checks. That change was merged in February and described as enabling larger functions. Reporting on the advisories notes it carried no mention of security at the time, and does not say when the security impact was recognised. The 36.x long-term-support line received the same fix on 19 October, seven months later.

WebAssembly's isolation model is enforced by the code the runtime generates, not by the hardware it runs on. Both October advisories are compiler-correctness defects, and both were rated 9.9 by the Bytecode Alliance.

Memory safety was never the control here

Wasmtime and Cranelift are written in Rust, and neither of these bugs is a buffer overflow. A memory-safe language prevents a compiler from corrupting its own state. It has nothing to say about whether the machine code that compiler emits honours a security boundary. That distinction is worth holding onto, because it is the one most often lost when a runtime is chosen on the strength of its implementation language.

The second practical point is distribution. Wasmtime is server infrastructure that ships inside other programs rather than beside them. It is a library, so updating a command-line tool or a package on a host fixes nothing: every binary that embeds the runtime has to be rebuilt against a patched version. Spin, the serverless WebAssembly project built on Wasmtime, moved to 50.0.0 in its 4.2.4 release on 21 October — the visible kind of update. The invisible kind is the internal service that vendored a runtime eighteen months ago and has not been rebuilt since.

The lever is size, not cleverness

What makes both bugs reachable is scale. One needs a function using more values than a 24-bit counter can express; the other needs a single br_table with a quarter of a million targets. They require a big input, and a compiler that accepts big inputs because accepting big inputs is its job.

That inverts a familiar intuition. A DDoS attack is recognisable precisely because volume is the attack. Here volume is also the attack, but it arrives as one upload of a few megabytes that a compilation pipeline is supposed to accept. Nothing in the request rate, the connection count or the network latency profile of that submission looks different from a customer deploying a large application.

Densely packed server racks in a data centre, the kind of multi-tenant tech infrastructure where a WebAssembly sandbox escape affects many tenants per host — Dense multi-tenant hosting. The number of tenants a single host can carry is what makes WebAssembly attractive, and what sets the blast radius if its isolation fails.

Density is the cloud security question

The exposure these advisories create is proportional to how much untrusted code a piece of tech infrastructure compiles. Fastly has said publicly that its Compute platform runs customer code on Wasmtime, and the same shape applies to plugin systems, edge functions and any service that accepts an uploaded module. The advisories themselves name no affected services and do not say what an attacker would reach after escaping; the honest statement is that a guest would gain whatever the host process holds.

That is the cloud security arithmetic worth doing before the patch window. A hypervisor escape is severe partly because a host runs tens of virtual machines. WebAssembly is chosen over heavier isolation precisely because a host can run thousands of instances, with start-up measured in microseconds. The density that makes the economics work is the same number that sets the blast radius when the primitive underneath it fails — and unlike a virtual machine, a Wasm instance has no second boundary behind the first.

Where resolution comes into it

A correctly functioning WebAssembly guest cannot make a DNS query at all. It has no sockets and no resolver unless the host hands it one, because WASI grants capabilities explicitly rather than inheriting the host's ambient authority. For a module that is supposed to be a pure computation, the first outbound name lookup attributable to that process is not a weak signal to be ranked against others. It is the boundary failing, written down with a timestamp.

Two caveats keep that from being a complete control. If the host deliberately grants an HTTP capability — many do, because modules need to call APIs — then lookups are expected, and the question becomes which names. And if that outbound path uses DNS over HTTPS to a public endpoint, the lookup never reaches the resolver whose logs you were planning to read. Encrypted resolution is the right default for a user's laptop and an awkward one for a host whose entire security model is the list of capabilities it grants. Decide which of your runtime hosts resolve through infrastructure you can see, before you need the log rather than after.

A network latency comparison of public DNS resolvers measured in the browser, the kind of baseline that makes a change in resolution behaviour on a host obvious — A resolver comparison run from the browser. A **network latency** baseline taken while a system is behaving normally is what later tells you that its resolution behaviour has changed.

What to check this week

Find the embedded copies, not the installed ones. Search your build manifests for wasmtime and cranelift, not your package lists. A rebuilt binary is the only thing that ships the fix.
Treat aarch64 hosts as the priority. Everything from 43.0.0 up to 48.0.6 is clean for the first bug and still exposed to the second, and a host patched in April against the earlier Arm escape is not covered by that update.
Check whether 24.x is still in service. That long-term-support line lost support on 20 August 2026 and received no fix for either issue.
Do not wait for an alert. Run cargo audit against RustSec directly; Dependabot has no reviewed entry for the aarch64 advisory, so no alert is expected for it.
Write down what your runtime grants. Filesystem, environment, socket and crypto capabilities are the whole of the IT security boundary once compilation is no longer trustworthy,.
Baseline what your hosts resolve. A network diagnostic tool run against the names your compute nodes reach tells you what normal looks like, which is the prerequisite for noticing the module that started asking for something else.

A DNS server performance benchmark measuring encrypted resolver response times from the browser, used to compare public DoH endpoints against each other — A **DNS server performance** benchmark against public resolvers. Measuring the endpoints a system actually depends on, rather than assuming them, is the same discipline as knowing which capabilities a runtime hands its guests.

What it means

The hedges in this tech infrastructure story deserve to be carried at full strength. No exploitation has been reported by the maintainers. Neither identifier was in CISA's Known Exploited Vulnerabilities catalogue as of 26 October. The GitHub advisories themselves record no known CVE, even as the CVE identifiers circulate in reporting and in the RustSec entries. And one of the two reports was submitted with AI assistance, which the advisory notes without further comment.

What generalises is the location of the trust. Every isolation technology asks you to believe something. A hypervisor asks you to trust silicon and a few tens of thousands of lines of privileged code. A WebAssembly runtime asks you to trust an optimising compiler to be correct on every input an adversary can construct — a much larger surface, re-executed for every module, and one where a seven-year-old 24-bit field and a branch instruction's range turn out to be security controls. The fix is a version bump. The lesson is that the boundary is produced, not installed.

Sources

Browse every DNS news article by month →

DNS angle

Review resolver logs for the systems discussed above and compare unexpected names with your approved services. A successful lookup does not establish that a destination is safe. Use the DNS lookup tool to inspect current answers, then compare them with your own resolver and incident records.

Source: The Hacker News — Two Critical Wasmtime Flaws Could Let Malicious WebAssembly Modules Escape Sandboxes (2026-10-26).