CVE-2025-58749
BaseFortify
Publication date: 2025-09-16
Last updated on: 2025-09-20
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| bytecodealliance | webassembly_micro_runtime | to 2.4.2 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-822 | The product obtains a value from an untrusted source, converts this value to a pointer, and dereferences the resulting pointer. |
| CWE-190 | The product performs a calculation that can produce an integer overflow or wraparound when the logic assumes that the resulting value will always be larger than the original value. This occurs when an integer value is incremented to a value that is too large to store in the associated representation. When this occurs, the value may become a very small or negative number. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
This vulnerability occurs in the WebAssembly Micro Runtime (WAMR) when running in LLVM-JIT mode. Specifically, if a WebAssembly program uses the memory.fill instruction with a memory address pointer greater than or equal to 2 GiB (2,147,483,648 bytes), the runtime fails to exit normally. Instead, it hangs in release builds or crashes in debug builds due to invalid pointer access. This issue is caused by improper handling of large memory addresses in the LLVM-JIT execution path and does not affect other modes like FAST-JIT. It was fixed in version 2.4.2. [1]
How can this vulnerability impact me? :
The vulnerability can cause the wasm-micro-runtime to hang indefinitely or crash when executing WebAssembly programs that use the memory.fill instruction with large memory addresses (>= 2 GiB) in LLVM-JIT mode. This can lead to denial of service by making the runtime unresponsive or unstable, potentially disrupting applications relying on WAMR for WebAssembly execution. [1]
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by running WebAssembly programs containing the memory.fill instruction with the first operand (memory address pointer) set to 2147483648 bytes (2 GiB) or higher in LLVM-JIT mode of wasm-micro-runtime (version prior to 2.4.2). If the runtime hangs or crashes, it indicates the presence of the vulnerability. A proof-of-concept WebAssembly module that invokes memory.fill with the first parameter set to 2147483648 and fills one byte with a value (e.g., 217) followed by a call to proc_exit can be used to test this. There are no specific commands provided, but executing such a test module in LLVM-JIT mode and observing for hangs or crashes is the detection method. [1]
What immediate steps should I take to mitigate this vulnerability?
The immediate mitigation step is to upgrade wasm-micro-runtime to version 2.4.2 or later, where this vulnerability has been fixed. The fix involves proper zero-extension of memory offsets in the LLVM-JIT execution path to prevent invalid pointer access and runtime hangs or crashes. Alternatively, avoid running WebAssembly programs with memory.fill instructions targeting memory addresses at or above 2 GiB in LLVM-JIT mode until the upgrade is applied. Using FAST-JIT mode or other runtime tools that do not exhibit this issue can also mitigate the risk. [1, 2]