CVE-2026-54912 · Runtime
NO FIX YET · SEE WHAT TO DO
WebAssembly Micro Runtime (WAMR) before 2.4.5 has a heap buffer overflow in its fast interpreter loader, triggered by a crafted module during loading. An attacker who supplies a malicious Wasm module can corrupt host heap metadata and deterministically crash the process, causing denial of service; further impact depends on the host application's heap layout.
first public Aug 4, 2026 · 1 source
Check it with your coding agent
It checks your repository and tells you if you’re affected, with the fix.
Applications that embed WAMR and load untrusted or attacker-supplied WebAssembly modules are exposed, and only builds with WAMR_BUILD_FAST_INTERP=1 are affected. Teams that run only trusted modules, or that build with the fast interpreter disabled, can deprioritize this; the sources say disabling the fast interpreter avoids the vulnerable loader.
Not affected if fast-interp-disabled, trusted-modules-only
Who cares embedded-runtime, wamr, webassembly
WAMR_BUILD_FAST_INTERP=1, which the sources say is required for the flaw.2.4.5.2.4.5 or later.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.
Are you affected?
Tell InfraStack what you run. It checks this one, and every next one, against your stack.
Ask from here. InfraStack checks the affected versions against your stack and answers in your inbox.
InfraStack checks the affected versions against your stack and answers in Slack, with the evidence and the fix.
This page as .md · .json · CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.