CVE-2026-54912 in WebAssembly Micro Runtime
Summary
by MITRE • 11/05/2026
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/wasm_loader.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, wasm_loader_get_const_offset emits later constants inline, but the between-pass sort and deduplication reduces the table so the second pass can choose table references and cause reserve_block_ret to emit additional copy operands that were not included in code_compiled_peak_size. 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 wasm_runtime_load, 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 WAMR_BUILD_FAST_INTERP=1 are affected; disabling the fast interpreter avoids the vulnerable loader. This issue is fixed in version 2.4.5.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 11/05/2026
The WebAssembly Micro Runtime, commonly known as WAMR, serves as a lightweight and standalone execution environment for WebAssembly modules, designed to operate efficiently on resource-constrained devices such as IoT endpoints and embedded systems. Within this runtime architecture, the interpreter component is responsible for parsing and executing bytecode instructions provided by guest applications. A critical security flaw exists in the two-pass fast interpreter loader mechanism located within the core iwasm interpreter module, specifically affecting builds where the WAMR_BUILD_FAST_INTERP flag is enabled to optimize execution performance through a faster interpretation path rather than traditional compilation or standard interpretation methods.
The technical root cause of this vulnerability lies in an inconsistency between the sizing pass and the emitting pass during the loading process of WebAssembly modules. The loader operates by first performing a sizing pass to determine memory requirements, followed by an emitting pass that actually constructs the executable code structures. In the flawed implementation, when duplicate constants within a module exceed the constant-slot limit during the initial sizing phase, the logic for determining how to store these constants diverges between the two passes. Specifically, while the first pass may decide to emit certain constants inline due to space constraints, the subsequent sorting and deduplication steps in the second pass can result in different decisions regarding table references. This discrepancy leads to a miscalculation of the required buffer size for compiled code data.
This logic error results in a heap-based buffer overflow condition where the second pass attempts to write partially attacker-controlled compiled-code data beyond the boundaries of the heap buffer that was allocated based on the undersized calculation from the first pass. Because this memory corruption occurs before any guest code is executed, it represents a pre-execution vulnerability that compromises the integrity of the host application's memory space immediately upon module loading. The overflow allows an attacker to corrupt host heap metadata structures, which are critical for managing dynamic memory allocation within the runtime environment.
The operational impact of exploiting this flaw is primarily a deterministic denial of service against the hosting process. By triggering the buffer overflow, an attacker can cause immediate and reliable crashes in the WAMR instance, disrupting services that rely on WebAssembly execution. Furthermore, depending on the specific heap layout and memory management implementation of the host application running WAMR, this out-of-bounds write could potentially be leveraged for more severe consequences such as arbitrary code execution or information disclosure, although the primary confirmed impact is process termination due to metadata corruption.
This vulnerability aligns with CWE-120, which describes buffer copy without checking size limits, and falls under the ATT&CK technique of Taint Analysis evasion through memory manipulation prior to execution. It highlights the risks associated with optimizing performance-critical paths in sandboxed environments where assumptions about input validity are not sufficiently enforced across all processing stages. The issue specifically impacts configurations utilizing the fast interpreter optimization path, leaving standard interpretation modes unaffected by this particular loader flaw.
To mitigate this risk, organizations deploying WebAssembly Micro Runtime must ensure they upgrade to version 2.4.5 or later, which contains the necessary corrections to align constant-table decisions between the sizing and emitting passes. For environments where upgrading is not immediately feasible, disabling the fast interpreter feature by unsetting the WAMR_BUILD_FAST_INTERP configuration flag during build time effectively avoids the vulnerable loader code path entirely. This workaround restores the default loading behavior that does suffer from this specific inconsistency, thereby preventing the heap overflow condition while potentially incurring a performance penalty associated with slower interpretation methods.