CVE-2026-54913 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, load_init_expr in core/iwasm/interpreter/wasm_loader.c accepts a non-reference heap-type byte for ref.null when WASM_ENABLE_GC=0, while the local WASMValue cur_value union is not zero-initialized and setting ref_index writes only part of it. A crafted module can declare an i64, f64, or v128 global initialized through the invalid ref.null form, causing push_const_expr_stack and the later global initialization path to copy uninitialized host-stack bytes into a value readable by the guest. The classic and fast interpreters are affected in the default no-GC configuration; the GC-enabled path validates heap types. The disclosure is four bytes for i64 or f64 globals and up to twelve bytes for each v128 global. This issue is fixed in version 2.4.5.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 11/05/2026
The WebAssembly Micro Runtime, commonly referred to as WAMR, serves as a lightweight standalone runtime environment designed to execute WebAssembly modules across various platforms including embedded systems and edge devices. A critical security vulnerability was identified within the core interpreter logic of versions prior to 2.4.5, specifically residing in the load_init_expr function located in the wasm_loader.c source file. This flaw emerges under specific configuration conditions where garbage collection support is disabled via the WASM_ENABLE_GC macro being set to zero. In this default no-GC configuration, the runtime fails to properly validate heap types associated with reference null operations, creating a pathway for memory corruption and information disclosure attacks against deployed WebAssembly applications.
The technical root cause of this vulnerability lies in improper initialization and validation procedures during module loading. When processing global variables that are initialized through an invalid ref.null form, the interpreter attempts to handle non-reference heap-type bytes without adequate safeguards. The local WASMValue union variable used to store intermediate values is not zero-initialized before use. Furthermore, when setting the ref_index field within this union, only a portion of the memory structure is overwritten with valid data while the remaining bytes retain their previous state on the host stack. This partial overwrite leaves residual uninitialized memory contents embedded within the value object that represents global variable initialization expressions.
During the execution flow, the push_const_expr_stack function and subsequent global initialization paths rely on these corrupted value structures to populate guest-accessible memory regions. Because the WASMValue union contains leftover data from previous operations or stack allocations, this uninitialized host-stack bytes are copied directly into the WebAssembly linear memory space. This mechanism effectively allows a crafted malicious module to read arbitrary portions of the host process's memory that were previously allocated but not cleared between uses. The vulnerability enables an attacker who controls the input WebAssembly module to exfiltrate sensitive data from the hosting environment, such as cryptographic keys, session tokens, or other confidential information residing in adjacent stack frames.
The operational impact is significant for applications relying on WAMR in untrusted execution environments where malicious modules may be loaded dynamically. The disclosure scope varies depending on the type of global variable being initialized through this flawed path. For i64 and f64 globals, which occupy eight bytes each, four bytes of uninitialized host memory are leaked to the guest environment. In cases involving v128 globals, which require sixteen bytes of storage, up to twelve bytes of sensitive host-stack data can be exposed. This partial disclosure is sufficient for many attack scenarios where even small amounts of high-entropy random data or pointers can facilitate further exploitation steps such as address space layout bypasses or state manipulation attacks against the hosting application logic.
This vulnerability aligns with CWE-908, which describes the use of uninitialized memory resources leading to unpredictable behavior and potential information leakage. From a threat modeling perspective utilizing the MITRE ATT&CK framework, this flaw facilitates Initial Access through malicious module injection and enables Credential Access or Discovery by allowing attackers to harvest sensitive host data without direct system-level privileges. The attack vector is classified as remote if the WebAssembly modules are fetched from untrusted sources over network connections, making it particularly dangerous for web-based applications or edge computing nodes that process user-supplied code artifacts.
Mitigation strategies primarily involve upgrading the WAMR runtime to version 2.4.5 or later where this issue has been resolved through proper initialization of value unions and stricter validation of heap types even in non-GC configurations. For organizations unable to immediately patch their dependencies, implementing strict allowlists for loaded WebAssembly modules can reduce exposure by preventing untrusted code from executing within the runtime environment. Additionally, enabling garbage collection support if architecturally feasible provides an additional layer of defense as the GC-enabled path correctly validates heap types and prevents this specific uninitialized memory leak vector. Security teams should also consider deploying sandboxing mechanisms or containerization strategies to limit the blast radius in case a compromised module attempts to exploit similar vulnerabilities in future versions.