CVE-2025-64713: WAMR Buffer Overflow Vulnerability

CVE-2025-64713 Overview

CVE-2025-64713 is an out-of-bounds array access vulnerability in WebAssembly Micro Runtime (WAMR), a lightweight standalone WebAssembly runtime maintained by the Bytecode Alliance. The flaw resides in WAMR's fast interpreter mode during WebAssembly (Wasm) bytecode loading. Specifically, when the frame_ref_bottom and frame_offset_bottom arrays reach capacity, processing a GET_GLOBAL(I32) opcode followed by an if opcode that triggers preserve_local_for_block can lead to out-of-bounds memory access. The issue is fixed in WAMR version 2.4.4.

Critical Impact
A crafted Wasm module loaded by an application embedding WAMR can trigger out-of-bounds memory access, leading to compromise of confidentiality, integrity, and availability of the host process.

Affected Products

Bytecode Alliance WebAssembly Micro Runtime (WAMR) prior to version 2.4.4
Applications and embedded systems embedding WAMR fast interpreter mode
Downstream projects bundling vulnerable WAMR versions

Discovery Timeline

2025-11-25 - CVE-2025-64713 published to the National Vulnerability Database
2025-11-25 - Bytecode Alliance security advisory GHSA-gvx3-gg3x-rjcx released
2025-12-03 - Last updated in NVD database

Technical Details for CVE-2025-64713

Vulnerability Analysis

The vulnerability is classified as an out-of-bounds array access [CWE-119] in the WAMR fast interpreter. WAMR uses two parallel arrays during bytecode loading: frame_ref_bottom tracks reference types, and frame_offset_bottom tracks operand offsets. Both arrays must remain synchronized in size with stack_cell_num, the interpreter's count of stack cells in use.

The defect appears when both arrays are at capacity. Encountering a GET_GLOBAL(I32) opcode expands frame_ref_bottom but does not consistently expand frame_offset_bottom. When the next opcode is an if that invokes preserve_local_for_block, the routine iterates using stack_cell_num as its upper bound. Because frame_offset_bottom was never resized to match the new stack_cell_num, the traversal reads and writes past the allocated buffer.

Root Cause

The root cause is a missing reallocation step. The two arrays are intended to grow in lockstep with stack_cell_num, but the GET_GLOBAL(I32) handler resizes only one of them. Subsequent code assumes both arrays are valid up to the new stack_cell_num, breaking that invariant.

Attack Vector

The attacker must supply a malicious Wasm module to an application that loads it using WAMR's fast interpreter. The attack is local, requires no privileges or user interaction, and depends on triggering the precise opcode sequence (GET_GLOBAL(I32) followed by an if triggering preserve_local_for_block) at the moment both arrays are saturated. Successful exploitation can corrupt adjacent heap memory, enabling code execution within the runtime process.

No public proof-of-concept exploit is available, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. See the GitHub Security Advisory GHSA-gvx3-gg3x-rjcx for additional technical context.

Detection Methods for CVE-2025-64713

Indicators of Compromise

Unexpected crashes, segmentation faults, or aborts in processes embedding WAMR while loading Wasm modules
Heap corruption signatures or AddressSanitizer reports referencing frame_offset_bottom during bytecode loading
Loading of unsigned or untrusted .wasm files from external sources or sandboxed plugins

Detection Strategies

Inventory binaries linked against libiwasm or WAMR source builds and identify versions earlier than 2.4.4
Run fuzzing harnesses against the fast interpreter loader using AddressSanitizer to catch the precise opcode sequence
Monitor application logs for parser errors or interpreter exceptions correlated with newly introduced Wasm modules

Monitoring Recommendations

Track process telemetry for embedded runtimes that load .wasm content from network, IPC, or file-based sources
Alert on creation or execution of Wasm modules from non-standard paths within IoT or edge devices
Audit software bills of materials (SBOMs) for transitive WAMR dependencies in firmware and container images

How to Mitigate CVE-2025-64713

Immediate Actions Required

Upgrade WAMR to version 2.4.4 or later in all build pipelines and deployed artifacts
Rebuild and redistribute downstream applications, firmware, and container images that statically link WAMR
Restrict loading of untrusted Wasm modules until patched versions are deployed across affected fleets

Patch Information

The maintainers fixed the vulnerability in WAMR-2.4.4. The patch ensures frame_offset_bottom is expanded consistently with frame_ref_bottom when stack capacity grows during bytecode loading. Details are documented in GitHub Security Advisory GHSA-gvx3-gg3x-rjcx.

Workarounds

Disable the fast interpreter mode and use the classic interpreter or AOT/JIT build options if upgrading is not immediately feasible
Enforce strict validation and provenance checks on Wasm modules before loading them into WAMR
Sandbox embedding processes using OS-level isolation to limit the blast radius of memory corruption

bash

# Build WAMR 2.4.4 with the fast interpreter disabled as a temporary workaround
git clone https://github.com/bytecodealliance/wasm-micro-runtime.git
cd wasm-micro-runtime
git checkout WAMR-2.4.4
cd product-mini/platforms/linux
mkdir build && cd build
cmake .. -DWAMR_BUILD_FAST_INTERP=0 -DWAMR_BUILD_INTERP=1
make -j$(nproc)