CVE-2026-54913: WebAssembly Micro Runtime: Missing `ref.null` heap-type validation in `load_init_expr` leaks host stack memory to the WebAssembly guest
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.
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
Event History
Frequently Asked Questions
Which deployments are affected?
WAMR versions before 2.4.5 are affected when using the classic or fast interpreter in the default configuration with WASM_ENABLE_GC=0. The GC-enabled path validates the ref.null heap type and is not affected by this specific issue.
What does an attacker need to exploit this issue?
An attacker needs to supply or cause the runtime to load a crafted WebAssembly module. The module uses an invalid ref.null form to initialize an i64, f64, or v128 global, allowing the guest to read uninitialized host-stack bytes.
What information can be disclosed?
The issue can disclose four bytes of host-stack memory for each affected i64 or f64 global, or up to twelve bytes for each affected v128 global. Integrity and availability impact are not described.
What should be done if an immediate upgrade is not possible?
Avoid loading untrusted WebAssembly modules on affected interpreter deployments. Enabling the GC path also avoids this specific missing heap-type validation, because that path validates heap types.