{"answers":{"affected":"It affects 1 product.","exploited":"It is not confirmed as exploited in the wild, but public exploit code for CVE-2025-58749 exists.","fix":"Upgrade to a fixed version.","what":"CVE-2025-58749 is a low-severity denial of service vulnerability in bytecodealliance wasm-micro-runtime, published on 16 Sep 2025. It can only be exploited from the same machine or local network, with no action from the victim."},"fix_prompt":"Check this codebase for CVE-2025-58749 and fix it if it is affected.\n\nWhat it is: CVE-2025-58749 is a low-severity denial of service vulnerability in bytecodealliance wasm-micro-runtime, published on 16 Sep 2025. It can only be exploited from the same machine or local network, with no action from the victim.\nExploitation: It is not confirmed as exploited in the wild, but public exploit code for CVE-2025-58749 exists.\n\nAffected product: bytecodealliance wasm-micro-runtime. No package-level version data is available, so check the vendor advisory linked from the reference page.\n\nTask:\n1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.\n2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.\n3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.\n4. Run the tests and summarise what changed and why.\n5. If nothing in the project is affected, say so and change nothing.\n\nReference: https://insights.sbomify.com/CVE-2025-58749/ (Markdown: https://insights.sbomify.com/CVE-2025-58749/index.md)","id":"CVE-2025-58749","markdown":"https://insights.sbomify.com/CVE-2025-58749/index.md","name":"CVE-2025-58749","record":{"aliases":["AZL-67608","AZL-67617","GHSA-xj5p-r8jq-pw47"],"analysis":{"component_type":"library","fix_type":"upgrade","impacts":["denial_of_service"],"network_reachable":"adjacent_or_local","non_default_config":true,"product_category":"WebAssembly runtime","requires_auth":"none","summary":"Attackers can cause the WAMR runtime to hang or crash by providing WebAssembly programs with large memory.fill addresses in LLVM-JIT mode.","user_interaction":"not_required","vuln_class":"denial_of_service"},"analysis_generated_by":"qwen3.8-flash-next","assigner":"GitHub_M","cpe":[{"product":"webassembly_micro_runtime","vendor":"bytecodealliance"}],"cvss":{"score":2.1,"severity":"low","source":"cna","vector":"CVSS:4.0/AV:L/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N","version":"4.0"},"cwes":[{"id":"CWE-822","name":"Untrusted Pointer Dereference"},{"id":"CWE-190","name":"Integer Overflow or Wraparound"}],"description":"WebAssembly Micro Runtime (WAMR) is a lightweight standalone WebAssembly (Wasm) runtime. In WAMR versions prior to 2.4.2, when running in LLVM-JIT mode, the runtime cannot exit normally when executing WebAssembly programs containing a memory.fill instruction where the first operand (memory address pointer) is greater than or equal to 2147483648 bytes (2GiB). This causes the runtime to hang in release builds or crash in debug builds due to accessing an invalid pointer. The issue does not occur in FAST-JIT mode or other runtime tools. This has been fixed in version 2.4.2.","ecosystems":[],"exploits":{"exploitdb":0,"first_seen":null,"github_poc":0,"max_poc_stars":null,"metasploit":0,"nuclei":0,"refs":[],"tier":"weaponised"},"has_fix":true,"headline":"WAMR runtime hangs or crashes with large memory.fill addresses in LLVM-JIT mode","id":"CVE-2025-58749","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":null,"product":null,"products":[],"type":"denial_of_service","year":"2025"},"n_packages":0,"n_references":2,"next":{"headline":"rAthena missing bound check in chclif_parse_moveCharSlot","id":"CVE-2025-58750"},"packages":[],"prev":{"headline":"Dataease H2 data source JDBC URL validation bypass leads to remote code execution","id":"CVE-2025-58748"},"products":["wasm-micro-runtime"],"published":"2025-09-16","related":[{"cvss_score":8.8,"headline":"Memory corruption in n/a","id":"CVE-2024-25431","kev_date_added":null,"published":"2024-11-08"},{"cvss_score":7.5,"headline":"Null dereference in n/a","id":"CVE-2024-27532","kev_date_added":null,"published":"2024-11-08"},{"cvss_score":7.5,"headline":"Memory corruption in n/a","id":"CVE-2024-34251","kev_date_added":null,"published":"2024-05-06"},{"cvss_score":7.5,"headline":"Memory corruption in n/a","id":"CVE-2023-48105","kev_date_added":null,"published":"2023-11-22"},{"cvss_score":7,"headline":"iwasm vulnerable to filesystem sandbox escape with symlink when using uvwasi feature","id":"CVE-2025-43853","kev_date_added":null,"published":"2025-05-15"},{"cvss_score":6.9,"headline":"WebAssembly Micro Runtime's `--addr-pool` option allows all IPv4 addresses when subnet mask is not specified","id":"CVE-2025-54126","kev_date_added":null,"published":"2025-07-29"},{"cvss_score":6.2,"headline":"Memory corruption in n/a","id":"CVE-2024-34250","kev_date_added":null,"published":"2024-05-06"}],"sources":[{"class":"attribution","licence":"CVE Terms of Use (MITRE)","name":"CVE List","prefix":"CVE"},{"class":"attribution","licence":"US public information, NVD API terms","name":"NVD"},{"class":"attribution","licence":"CWE Terms of Use","name":"CWE (MITRE)"},{"class":"attribution","licence":"FIRST CVSS licence","name":"CVSS (FIRST)"}],"ssvc":{"automatable":"no","exploitation":"poc","technical_impact":"partial"},"state":"PUBLISHED","updated":"2025-09-16","vendors":["bytecodealliance"]},"summary":"Attackers can cause the WAMR runtime to hang or crash by providing WebAssembly programs with large memory.fill addresses in LLVM-JIT mode.","url":"https://insights.sbomify.com/CVE-2025-58749/"}