WebAssembly Micro Runtime (WAMR) is a lightweight standalone WebAssembly (Wasm) runtime. Prior to 2.4.5, loadinitexpr in core/iwasm/interpreter/wasmloader.c accepts a non-reference heap-type byte for ref.null when WASMENABLEGC=0, while the local WASMValue curvalue union is not zero-initialized and setting refindex writes only part of it. A crafted module can declare an i64, f64, or v128 global initialized through the invalid ref.null form, causing pushconstexprstack 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.

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.