CVE-2021-32629: Cranelift x64 Backend Sandbox Escape in Wasmtime
Summary
CVE-2021-32629: Cranelift is an open-source code generator maintained by Bytecode Alliance. Affects wasmtime across 2 version ranges.
< 0.27.0
< 95559c01aaa7c061088a433040f31e8291fb09d0
Fixed in 95559c01aaa7c061088a433040f31e8291fb09d0. How to fix ↓
Also tracked for
- cranelift-codegen · crates.io
- cranelift-codegen · crates.io
- cranelift-codegen · crates.io
The same CVE-2021-32629 is tracked separately for each ecosystem and vendor. Its fix information is the same; the package and affected versions differ.
Check if this vulnerability affects your application
Upload a manifest or SBOM and we'll show whether you're affected, plus every other risky package in the same scan.
No signup required · Results in about 60 seconds
Background
Cranelift is an open-source code generator maintained by Bytecode Alliance. It translates a target-independent intermediate representation into executable machine code. Wasmtime is a runtime for WebAssembly that uses Cranelift as its code generator. The Cranelift x64 backend in version 0.73 of Cranelift has a bug that can potentially result in a sandbox escape in a Wasm program. This bug was introduced in the new backend on September 8, 2020, and first included in a release on September 30, 2020. The bug performs a sign-extend instead of a zero-extend on a value loaded from the stack, under specific circumstances. If these circumstances occur, the bug could allow access to memory addresses up to 2GiB before the start of the Wasm program heap. The impact of this bug depends on the heap implementation and whether memory is mapped in the accessible range.
Vulnerability Detail
The vulnerability occurs when an i32 value in a Wasm program is greater than or equal to 0x8000_0000, and it is spilled and reloaded by the register allocator due to high register pressure. If the value is produced by a special instruction that zeroes the upper 32 bits of its destination, and it is zero-extended to 64 bits in the Wasm program, a sandbox escape can occur. This allows the program to reach backward and access memory up to 2GiB before the start of its heap. The impact of the vulnerability depends on the heap implementation and whether memory is mapped in the accessible range.
How To Fix
Latest published version: 50.0.1 as of 22 Oct 2026
pip install --upgrade "wasmtime==50.0.1"Upgrading to it may include breaking changes; the version below is the minimum fixed release for this vulnerability.
If you need the minimum change
95559c01aaa7c061088a433040f31e8291fb09d0
This is the first release that contains the fix.
pip install --upgrade "wasmtime==95559c01aaa7c061088a433040f31e8291fb09d0"Tip — Not sure which version your app runs? Vulert can match this fix to it. Scan free →
Workaround
There is no specific workaround mentioned for this vulnerability.
Conclusion
The Cranelift x64 backend in version 0.73 of Cranelift has a bug that can potentially result in a sandbox escape in a Wasm program. This bug was introduced in the new backend on September 8, 2020, and first included in a release on September 30, 2020. To fix the vulnerability, it is recommended to update to version 0.27.0 or later of Wasmtime, which includes a fix for this issue. Users of Cranelift should update to version 0.73 or later, or use an explicit build flag to select the old backend. For further support on vulnerability remediation, contact DevNack.com.
See every vulnerability recorded for wasmtime →
FAQ
Cranelift is an open-source code generator maintained by Bytecode Alliance. It translates a target-independent intermediate representation into executable machine code.
Wasmtime is a runtime for WebAssembly that uses Cranelift as its code generator.
The vulnerability affects version 0.73 of the Cranelift x64 backend, which was released on September 30, 2020. Prior versions with an explicit build flag to select the new backend are also vulnerable.
The impact of the vulnerability depends on the heap implementation and whether memory is mapped in the accessible range. If the heap has bounds checks, does not rely exclusively on guard pages, and the heap bound is 2GiB or smaller, the bug cannot be used to reach memory from another Wasm program heap. However, if the heap bound is larger than 2GiB, it would be possible to read memory from a computable range dependent on the size of the heap bound.
The impact of the vulnerability can be mitigated if there is no memory mapped in the range accessible using this bug. For example, having a 2 GiB guard region before the Wasm program heap can prevent the bug from being exploited.
Related vulnerabilities
Recent vulnerabilities recorded for wasmtime.
