Two Wasmtime Sandbox Escapes Patched: What the Fixes Mean for Anyone Running Untrusted Code

Key points

• The ARM64 flaw has sat in Wasmtime since the platform was first supported in 2020, meaning every aarch64 build before this month's patches can be made to jump to attacker-chosen code.
• Two separate advisories were published by the Bytecode Alliance against Wasmtime, a program that runs WebAssembly code inside a safety box so it cannot touch the rest of the system.
• The first bug, GHSA-897f-g5gm-fmxm, is a counter overflow in the Cranelift compiler that lets a very large or carefully built module escape the sandbox on any platform.
• The second, GHSA-mghf-wjfp-p5xm, only hits ARM64 chips but can be triggered through a single oversized branch table.
• Patched builds are Wasmtime v36.0.19, v48.0.7 and v49.0.4; the compiler bug is also fixed in the mainline v43 release.

Wasmtime is one of the quieter pieces of modern software. It runs WebAssembly, a portable code format originally built for browsers, inside a sealed container so the code cannot read your files or talk to the network unless you let it. Cloud platforms, plugin systems and edge functions all use it to run code written by someone else without trusting that someone.

Two new advisories from the Bytecode Alliance, which maintains the project, say that container can be broken out of.

What exactly went wrong?

Both bugs sit in Cranelift, the compiler Wasmtime uses to turn WebAssembly into native machine code. Cranelift translates each module before it runs, and the translation step is where the mistakes happened.

The first flaw is a counter that runs out of room. Cranelift packs the internal identifiers for values in a program into a tight numeric field. A WebAssembly function large enough, or deliberately shaped to burn through those identifiers, overflows the counter silently in release builds. The compiler then starts mixing up which value is which, and an attacker can steer that confusion into a full sandbox escape. The project's own writeup calls it "arbitrary miscompilation." It affects every platform using default settings.

The second is narrower but older. On ARM64 chips, the kind in Apple Silicon Macs, AWS Graviton servers and most phones, Cranelift mishandles a br_table instruction (a jump table used by compiled switch statements) once it has more than roughly 256,000 entries. The resulting branch can land at an offset the attacker chose. Every Wasmtime release that has ever supported ARM64, going back to before version 1.0 in 2020, carries the bug.

Who is actually at risk?

Anyone running a Wasmtime engine that executes WebAssembly modules supplied by other people. That is the whole point of the runtime, so for most users the honest answer is: yes, you.

Serverless platforms that accept customer code, plugin hosts that load third-party extensions, and SaaS products that embed Wasmtime to sandbox user scripts all fit the pattern. A read-only site that compiles its own trusted modules at build time is not in the firing line, but that is not how most deployments look.

As The Hacker News noted in its writeup, the attacker needs to control the module being compiled. They do not need credentials, a foothold or any other access.

What to patch

The practical move is to jump to v49.0.4 if you are on a current branch, or to one of the backported point releases if you are pinned to an older line. Both advisories cover the same v36.0.19 build, so a single upgrade clears both bugs for anyone still on that series.

One honest note on authentication, since it is my beat: neither of these is an auth bug and no amount of multi-factor login would have stopped them. The trust boundary here is the sandbox itself, and the sandbox is what failed. Patch the runtime.