Skip to main content
VulnerabilityPublished

CVE-2025-54126: bytecodealliance wasm-micro-runtime · Resource Exposure

Affects bytecodealliance wasm-micro-runtimeSource CVE Database V5

0

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

CVSS 4.0 base score
6.9Medium
How severe the flaw is on the 0–10 CVSS scale.
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:N

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 29 Jul 2025

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq 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

ProductAffectedFixed in
GitHubbytecodealliance/wasm-micro-runtimepkg:github/bytecodealliance/wasm-micro-runtimeOther threatsAffected
  • <2.4.1
Fixed in
  • 2.4.1

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

Community reviews

Loading reviews…