CVE-2025-6274: 
NixOS vulnerability analysis and mitigation

CVE-2025-6274 is an uncontrolled resource consumption vulnerability in WebAssembly Binary Toolkit (wabt) affecting versions up to and including 1.0.37. The flaw resides in the OnDataCount function within src/interp/binary-reader-interp.cc, where a specially crafted WebAssembly binary can trigger excessive memory allocation, leading to an out-of-memory condition. It was publicly disclosed on June 19, 2025, with a proof-of-concept exploit filed via a GitHub issue on May 13, 2025. The vulnerability carries a CVSS v3.1 base score of 3.3 (Low) and a CVSS v4.0 base score of 1.9 (Low) (Red Hat Advisory, GitHub Issue).

The root cause is classified as CWE-400 (Uncontrolled Resource Consumption) and CWE-404 (Improper Resource Shutdown or Release). When parsing a malicious WebAssembly binary, the BinaryReaderInterp::OnDataCount(unsigned int) function at line 772 of src/interp/binary-reader-interp.cc attempts to allocate memory proportional to an attacker-controlled data count value without adequate bounds checking, causing the allocator to request an extremely large block (e.g., ~0x7a9a346848 bytes) and crash with an out-of-memory error. Exploitation requires local access and low privileges; the attacker supplies a crafted .wasm file as input to a wabt tool such as the read_binary_interp fuzzer harness. A public PoC crash file and reproduction steps have been disclosed on GitHub (GitHub Issue, Red Hat Bugzilla).

Successful exploitation causes an out-of-memory crash in the wabt process, resulting in a partial denial of service (availability impact). There is no impact on confidentiality or integrity. The scope is limited to the local system and the wabt toolchain process itself; lateral movement or data exfiltration are not realistic outcomes given the local-only attack vector and the nature of the crash (Red Hat Advisory, GitHub Issue).

A proof-of-concept crash file (wabt_crash_4.txt) and detailed reproduction steps have been publicly disclosed on GitHub, discovered through fuzzing with the OSS-Fuzz read_binary_interp_fuzzer harness (GitHub Issue). There is no evidence of in-the-wild exploitation, no known threat actor attribution, and the vulnerability is not listed in the CISA KEV catalog. The EPSS score is approximately 0.013% (0.000130), reflecting very low probability of exploitation in the near term. The wabt maintainers have noted that a similar concurrent issue was disputed as not affecting "real world wasm programs," and this entry may be disputed in the future (Red Hat Bugzilla).

1. Prepare environment: Install wabt (version ≤ 1.0.37) on a Linux system with Clang and AddressSanitizer support.
2. Build fuzzer harness: Compile the read_binary_interp_fuzzer from the OSS-Fuzz project against the wabt library with ASan enabled (-fsanitize=address -fsanitize=fuzzer).
3. Obtain or craft malicious input: Download the public PoC crash file (wabt_crash_4.txt) from https://github.com/user-attachments/files/20191325/wabt_crash_4.txt, which contains a specially crafted WebAssembly binary with an inflated data count value.
4. Trigger the vulnerability: Run the fuzzer harness with the crafted input: ./read_binary_interp_fuzzer wabt_crash_4.txt. The OnDataCount function attempts to allocate ~512 GB of memory based on the malicious count field.
5. Observe crash: The process aborts with AddressSanitizer: allocator is out of memory trying to allocate 0x7a9a346848 bytes, crashing the wabt tool (GitHub Issue).

• Process: Abnormal termination of wabt tools (e.g., wasm-interp, wasm2wat) with out-of-memory errors or signals such as SIGABRT.
• Logs: AddressSanitizer output containing allocator is out of memory and stack traces referencing BinaryReaderInterp::OnDataCount in src/interp/binary-reader-interp.cc:772.
• File System: Presence of unexpected or malformed .wasm files provided as input to wabt tools, particularly files with anomalously large data count section values.
• System: Sudden spike in memory consumption by a wabt process followed by immediate process termination (GitHub Issue).

Users should upgrade WebAssembly wabt to a version beyond 1.0.37 once a patched release is available. In the interim, restrict local user access to wabt tools and avoid processing untrusted WebAssembly binaries. Implementing resource limits (e.g., ulimit -v) on processes running wabt can reduce the impact of memory exhaustion. Applying the principle of least privilege for users interacting with wabt is also recommended (Red Hat Advisory, Red Hat Bugzilla).

Red Hat tracked the issue via Bugzilla and assigned it low priority and severity, noting the upstream report and the possibility that the entry may be disputed by the wabt maintainers, consistent with a similar concurrent issue that was disputed as not affecting real-world wasm programs (Red Hat Bugzilla). The vulnerability was reported by researcher Yifan Zhang (PLL) via the wabt GitHub issue tracker and has received limited broader community attention given its low severity and local-only attack vector (GitHub Issue).