The vulnerability CVE-2025-64713 affects the bytecodealliance wasm-micro-runtime (WAMR), a lightweight standalone WebAssembly runtime used for executing WASM bytecode in constrained environments. The flaw exists in versions prior to 2.4.4 within the fast interpreter mode during the loading of WASM bytecode. Specifically, when the internal arrays frame_ref_bottom and frame_offset_bottom reach their capacity and a GET_GLOBAL(I32) opcode is processed, frame_ref_bottom is expanded but frame_offset_bottom may not be correspondingly expanded. If this is immediately followed by an if opcode that triggers the preserve_local_for_block function, the runtime traverses these arrays using stack_cell_num as the upper bound. Because frame_offset_bottom was not expanded, this traversal causes an out-of-bounds access, leading to memory corruption. This is classified under CWE-119 (Improper Restriction of Operations within the Bounds of a Memory Buffer). The vulnerability can cause a denial of service by crashing the runtime or corrupting memory, but it does not allow for privilege escalation or data leakage. Exploitation requires local access to the runtime environment and has a high attack complexity, with no user interaction needed. The issue was addressed and patched in version 2.4.4 of WAMR. No public exploits have been reported to date.

For European organizations, the primary impact of this vulnerability is the potential for denial of service in applications relying on WAMR for WebAssembly execution, particularly in embedded, IoT, or edge computing scenarios where WAMR is favored for its lightweight footprint. Service interruptions could affect critical infrastructure or industrial control systems that utilize WASM runtimes for automation or processing tasks. Although the vulnerability does not compromise confidentiality or integrity, availability disruptions can lead to operational downtime and associated financial or safety risks. Organizations with deployments in manufacturing, automotive, telecommunications, or smart city applications may be particularly vulnerable. The requirement for local access and high attack complexity somewhat limits the risk of remote exploitation, but insider threats or compromised local systems could leverage this flaw. The absence of known exploits reduces immediate risk but underscores the importance of timely patching to prevent future attacks.

The most effective mitigation is to upgrade all instances of wasm-micro-runtime to version 2.4.4 or later, where the out-of-bounds access issue has been fixed. Organizations should conduct an inventory of systems using WAMR, especially in embedded and edge environments, to ensure no vulnerable versions remain in production. For environments where immediate upgrading is not feasible, implementing strict access controls to limit local access to trusted users and processes can reduce exploitation risk. Additionally, monitoring runtime logs and system behavior for crashes or anomalies related to WASM execution can help detect attempted exploitation. Security teams should also review and harden the supply chain and deployment pipelines for WASM modules to prevent injection of malicious bytecode sequences that could trigger the vulnerability. Finally, integrating memory safety tools or runtime protections where possible can provide additional defense-in-depth.