CVE-2025-15411: 
NixOS vulnerability analysis and mitigation

CVE-2025-15411 is a heap-buffer-overflow (memory corruption) vulnerability in the wasm-decompile component of WebAssembly Binary Toolkit (wabt) versions up to and including 1.0.39. The flaw resides in the wabt::AST::InsertNode function within src/repro/wabt/bin/wasm-decompile and is triggered when processing a specially crafted WebAssembly binary. It was reported on December 8, 2025, and published as a CVE on January 1, 2026 (GitHub Issue, VulDB). The CVSS v3.1 base score assigned by NVD is 7.8 (High), while the CNA (VulDB) rates it 5.3 (Medium); the CVSS 4.0 score is 1.9 (Low) (NVD).

The root cause is a pointer invalidation (use-after-free / out-of-bounds read) classified as CWE-119 (Improper Restriction of Operations within the Bounds of a Memory Buffer). When wabt::AST::InsertNode is called during decompilation, an internal std::vector<wabt::Node> undergoes reallocation (_M_realloc_insert), freeing its old memory buffer. A stale pointer or reference to an element in that freed buffer is subsequently dereferenced, resulting in a heap-buffer-overflow READ of size 8 at the freed address (GitHub Issue). Exploitation requires a local attacker to supply a malicious .wasm binary file to the wasm-decompile tool; no network access or elevated privileges are needed beyond local user access. A public proof-of-concept reproducer file (af1) is available (PoC File).

Successful exploitation can cause a crash of the wasm-decompile process (Denial of Service) or, in more severe scenarios, memory corruption that could potentially be leveraged for arbitrary code execution in the context of the user running the tool. Confidentiality, integrity, and availability of the affected process are all at risk, as reflected in the NVD CVSS v3.1 score of 7.8 (High) with High impacts across all three dimensions (NVD). The vulnerability is limited to local attack scenarios and does not directly enable lateral movement or remote exploitation; however, it could be used in developer or CI/CD pipeline environments where untrusted .wasm files are processed (GitHub Issue).

A public proof-of-concept reproducer binary (af1) has been published by the reporter, making exploitation straightforward for anyone with local access (PoC File). The EPSS score is approximately 0.015% (0.000150), indicating a very low probability of widespread exploitation in the near term (Feedly). There is no evidence of in-the-wild exploitation, no known threat actor attribution, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Notably, the wabt project currently lacks an active maintainer, meaning no official patch has been issued and the issue remains open (GitHub Issue).

1. Obtain the PoC: Download or craft a malicious WebAssembly binary file designed to trigger vector reallocation during decompilation. The public reproducer (af1) is available at the reporter's GitHub repository (PoC File).
2. Identify a target: Locate a system where wabt version ≤ 1.0.39 is installed and the wasm-decompile binary is accessible to a local low-privileged user.
3. Execute the exploit: Run the wasm-decompile tool against the malicious binary: ./wasm-decompile ./af1. This triggers the wabt::AST::Construct → wabt::AST::InsertNode call chain, causing std::vector<wabt::Node> reallocation and subsequent stale pointer dereference.
4. Observe the crash: The process crashes with a heap-buffer-overflow (READ of size 8) at the freed memory address, as confirmed by AddressSanitizer output. In a non-ASan build, this may result in silent memory corruption or exploitable conditions depending on heap layout (GitHub Issue).

• Process: Unexpected crash or abort of the wasm-decompile process; core dumps generated by the wasm-decompile binary.
• Logs: AddressSanitizer output containing heap-buffer-overflow in wabt::AST::InsertNode and references to _M_realloc_insert in stack traces; messages such as ==XXXXX==ERROR: AddressSanitizer: heap-buffer-overflow in application logs.
• File System: Presence of unusual or externally supplied .wasm binary files in directories processed by wasm-decompile; core dump files (e.g., core.*) in the working directory of the tool.
• Network: No network-based IOCs are expected, as this is a local attack vector (GitHub Issue).

No official patch has been released, as the wabt project currently has no active maintainer (GitHub Issue). The community has suggested that the reporter or other contributors submit a pull request to fix the stale pointer issue in wabt::AST::InsertNode. As a workaround, organizations should avoid running wasm-decompile on untrusted or externally supplied WebAssembly binaries, and should restrict access to the tool to trusted users only. Running the tool in a sandboxed or containerized environment can limit the blast radius of exploitation. Users should monitor the wabt GitHub repository for any community-contributed fixes or new releases.

The vulnerability was reported via a GitHub issue by researcher "oneafter" on December 8, 2025, with a detailed ASan report and a public reproducer (GitHub Issue). A community member responding to the issue noted the lack of an active maintainer and suggested the researcher submit a PR themselves, highlighting the open-source maintenance gap. The issue has been labeled sanitizer failure and wasm-decompile by the repository. Coverage has been picked up by automated vulnerability tracking services including VulDB, CIRCL Vulnerability Lookup, and ENISA EUVD, but no significant security researcher commentary or media coverage beyond routine aggregation has been observed (VulDB).