CVE-2025-6275
BaseFortify
Publication date: 2025-06-19
Last updated on: 2026-04-29
Assigner: VulDB
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| webassembly | wabt | to 1.0.37 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-119 | The product performs operations on a memory buffer, but it reads from or writes to a memory location outside the buffer's intended boundary. This may result in read or write operations on unexpected memory locations that could be linked to other variables, data structures, or internal program data. |
| CWE-416 | The product reuses or references memory after it has been freed. At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation. Any operations using the original pointer are no longer valid because the memory "belongs" to the code that operates on the new pointer. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
CVE-2025-6275 is a heap-use-after-free vulnerability in the WebAssembly Binary Toolkit (wabt) up to version 1.0.37. It occurs in the function GetFuncOffset within the source file src/interp/binary-reader-interp.cc. The vulnerability arises when the program improperly manages memory, specifically when it accesses memory that has already been freed during the processing of WebAssembly binary instructions. This happens due to unsafe handling of an error vector, where an error is added after the underlying buffer has been freed, causing a dangling pointer dereference. Exploiting this flaw requires local access and specially crafted input, potentially leading to program crashes or denial of service. [1, 2, 3]
How can this vulnerability impact me? :
This vulnerability can impact you by causing denial of service (DoS) through program crashes or unexpected behavior when processing maliciously crafted WebAssembly binaries. Since it is a use-after-free bug, it may also lead to undefined behavior or potentially arbitrary code execution, although no direct evidence of code execution is documented. Exploitation requires local access to the system, and the vulnerability affects the availability of the affected software. There are no known mitigations, so replacing the affected product version is recommended. [1, 2, 3]
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by reproducing the use-after-free condition using fuzz testing tools such as OSS-Fuzz with the wabt binary interpreter. Specifically, running the fuzzing harness `read_binary_interp_fuzzer.cc` with AddressSanitizer enabled can help detect the heap-use-after-free in the function GetFuncOffset. A proof-of-concept crash file (`wabt_crash_5.txt`) is available to trigger the issue. Commands would involve building wabt with AddressSanitizer and running the fuzzer or the PoC crash file to observe the crash. For example, compiling wabt with Clang and AddressSanitizer flags, then executing the fuzzer or loading the crash file to trigger the vulnerability. [3]
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation steps include replacing the affected wabt version (up to 1.0.37) with a non-vulnerable alternative or updated version if available. Since no known countermeasures or patches are documented, avoiding use of the vulnerable function or restricting local access to the affected system can reduce risk. Monitoring for updates from the wabt maintainers and applying patches once released is recommended. [2]