CVE-2025-54126: bytecodealliance wasm-micro-runtime · Resource Exposure
Affects bytecodealliance wasm-micro-runtimeSource CVE Database V5
Not known to be exploited · CVSS 6.9 Medium : upgrade to 2.4.1 when convenient.
Data as of 26 Oct 2026, 12:29 UTC
- EPSS
- 0.6% chance of exploitation in 30 days – higher than 51% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
- Patch
- Available – fixed in 2.4.1
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:L/SI:N/SA:NExploitation evidence
Disclosed: evidence found.
CVE published 29 Jul 2025
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.
What to do
Upgrade bytecodealliance/wasm-micro-runtime to 2.4.1.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
GitHubbytecodealliance/wasm-micro-runtimepkg:github/bytecodealliance/wasm-micro-runtimeOther threats | Affected
| Fixed in
|
Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.
AI-suggested
European organizations should immediately audit their deployments of wasm-micro-runtime, specifically the iwasm component, to identify versions below 2.4.1. They should upgrade all affected instances to version 2.4.1 or later, where the vulnerability is fixed. Until upgrades can be performed, organizations should avoid using the --addr-pool parameter without explicitly specifying a subnet mask to ensure proper IP filtering. Network-level controls such as firewall rules and intrusion prevention systems should be configured to restrict access to the affected services to trusted IP ranges. Additionally, organizations should implement monitoring and logging of access attempts to detect any unauthorized connection attempts. Security teams should review configuration management and deployment pipelines to prevent insecure defaults from being propagated. Finally, penetration testing and vulnerability scanning should include checks for this specific misconfiguration to proactively identify exposure.
Description
The WebAssembly Micro Runtime's (WAMR) iwasm package is the executable binary built with WAMR VMcore which supports WebAssembly System Interface (WASI) and command line interface. In versions 2.4.0 and below, iwasm uses --addr-pool with an IPv4 address that lacks a subnet mask, allowing the system to accept all IP addresses. This can unintentionally expose the service to all incoming connections and bypass intended access restrictions. Services relying on --addr-pool for restricting access by IP may unintentionally become open to all external connections. This may lead to unauthorized access in production deployments, especially when users assume that specifying an IP without a subnet mask implies a default secure configuration. This is fixed in version 2.4.1.
References
- github.com/bytecodealliance/wasm-micro-runtime/security/advisories/GHSA-vh64-mfvw-pxqp (opens in a new tab)
- github.com/bytecodealliance/wasm-micro-runtime/commit/121232a9957a069bbb04ebda053bdc72ab409e7a (opens in a new tab)
- github.com/bytecodealliance/wasm-micro-runtime/releases/tag/WAMR-2.4.1 (opens in a new tab)