CVE-2025-6273
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 (inc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-617 | The product contains an assert() or similar statement that can be triggered by an attacker, which leads to an application exit or other behavior that is more severe than necessary. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
CVE-2025-6273 is a vulnerability in the WebAssembly Binary Toolkit (wabt) up to version 1.0.37, specifically in the function LogOpcode within the source file src/binary-reader-objdump.cc. The vulnerability is an assertion failure triggered when processing malformed or corrupted WebAssembly binaries, such as those with invalid section codes or load alignments. This assertion failure causes the program to crash, leading to a denial of service. Exploitation requires local access and specially crafted input. The code maintainer has expressed doubts about its impact on real-world wasm programs. [1, 2, 3]
How can this vulnerability impact me? :
This vulnerability can cause the wabt tool to crash when processing specially crafted WebAssembly binaries, resulting in a denial of service (DoS). Since the tool aborts due to an assertion failure, availability of the tool or service relying on it can be disrupted. Exploitation requires local access and crafted input, so remote exploitation is not applicable. The impact is limited to availability and does not affect confidentiality or integrity. [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 testing the wabt tool (version up to 1.0.37) with specially crafted malformed or corrupted WebAssembly (wasm) binaries that trigger the assertion failure in the LogOpcode function. Detection involves running fuzz testing tools such as wasm_objdump_fuzzer with AddressSanitizer and libFuzzer enabled on the wabt source code. A specific test involves using a crafted input file (e.g., wabt_crash.in) that contains invalid section codes or load alignments to reproduce the crash. There are no known network detection commands since the exploit requires local access and targets local processing of wasm files. [3]
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation steps include avoiding the use of wabt versions up to 1.0.37 for processing untrusted wasm binaries, as no known countermeasures exist. Consider using alternative tools or updated versions of wabt if available. Since the vulnerability requires local access and triggers a denial of service by crashing the tool, restricting access to the wabt tool and validating wasm inputs before processing can reduce risk. Monitoring for updates or patches from the maintainers is also recommended. [2]