CVE-2026-54912: WAMR fast interpreter loader heap buffer overflow via constant deduplication mismatch
WebAssembly Micro Runtime (WAMR) is a lightweight standalone WebAssembly (Wasm) runtime. Prior to 2.4.5, the two-pass fast interpreter loader in core/iwasm/interpreter/wasmloader.c can make inconsistent constant-table decisions between the sizing pass and the emitting pass. After duplicate constants inflate the first pass beyond the constant-slot limit, wasmloadergetconstoffset emits later constants inline, but the between-pass sort and deduplication reduces the table so the second pass can choose table references and cause reserveblockret to emit additional copy operands that were not included in codecompiledpeaksize. A crafted module can therefore make the second pass write partially attacker-controlled compiled-code data beyond the heap buffer allocated from the first pass's size calculation during wasmruntimeload, before guest code executes. This can corrupt host heap metadata and deterministically crash the process, causing denial of service; further consequences depend on the host application's heap layout. Builds using WAMRBUILDFASTINTERP=1 are affected; disabling the fast interpreter avoids the vulnerable loader. This issue is fixed in version 2.4.5.
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
WebAssembly Micro Runtime (WAMR)to a version that resolves this vulnerability.Fixed in 2.4.5 - Configuration
Disable the fast interpreter to avoid the vulnerable loader.
WAMR WAMR_BUILD_FAST_INTERP = disabled
Event History
Frequently Asked Questions
Which WAMR deployments are affected?
Deployments using a WAMR version earlier than 2.4.5 with WAMR_BUILD_FAST_INTERP=1 are affected. Disabling the fast interpreter avoids the vulnerable loader.
What does an attacker need to exploit this issue?
An attacker needs to cause the runtime to load a crafted WebAssembly module containing duplicate constants that trigger the sizing and emitting pass mismatch. No privileges or user interaction are required according to the supplied severity vector.
Does guest code need to run for exploitation to occur?
No. The out-of-bounds write occurs during wasm_runtime_load while compiling/loading the module, before guest code executes.
What should be done if upgrading is not immediately possible?
Disable the fast interpreter so that WAMR_BUILD_FAST_INTERP is not enabled. Upgrade to version 2.4.5 when possible.
What is the practical impact of successful exploitation?
The flaw can corrupt host heap metadata and deterministically crash the process, causing denial of service. Further consequences depend on the host application's heap layout.