GHSA-3p27-qvp9-27qf CVE-2026-54786 RUSTSEC-2026-0182
Wasmtime has a leak in WASIp1 `fd_renumber` implementation
- Severity
- 0.0 / 10
- Medium · CVSS 4.0
- Exploit chance (EPSS)
- 0.37%
- Chance of exploitation in the next 30 days. Higher than 30.60% of scored vulnerabilities.
- Known exploited
- No
- Not in CISA's catalog
- Weakness
- CWE-400 Uncontrolled Resource Consumption
- Fix
24.0.10- Upgrade wasmtime-wasi to this version or later
Description
Impact
Wasmtime's native implementation of WASIp1 suffers from a leak in the fd_renumber function where the file descriptor being renumbered to is not properly closed. Wasmtime's implementation erroneously only updated the table of descriptors for WASIp1 and didn't update the underlying table of descriptors used by the host. This behavior means that while fd_renumber works correctly from a guest's perspective it ends up leaking resources in the host that aren't cleaned up until the corresponding Store is destroyed. This means that guests can, in a loop, use fd_renumber to cause hosts to exhaust resources or exhaust file descriptors.
This bug only affects the native implementation of WASIp1. This means that only runtimes which load core wasm modules and expose fd_renumber are affected. Runtimes are additionally only affected if they expose the ability to acquire a file descriptor, such as opening a file. For runtimes that deny access to files they are unaffected.
Patches
Wasmtime 24.0.10, 36.0.11, 44.0.3, and 45.0.2 have been released which fix this issue.
Workarounds
There are no workarounds for this issue and hosts are recommended to update.
Affected versions
crates.io
| Package | Vulnerable | Fixed in |
|---|---|---|
| wasmtime-wasi | < 24.0.10 |
24.0.10 |
| wasmtime-wasi | >= 45.0.0, < 45.0.2 |
45.0.2 |
| wasmtime-wasi | >= 25.0.0, < 36.0.11 |
36.0.11 |
| wasmtime-wasi | >= 37.0.0, < 44.0.3 |
44.0.3 |
| wasmtime-wasi | >= 0.0.0-0, < 24.0.10>= 25.0.0, < 36.0.11>= 37.0.0, < 44.0.3>= 45.0.0, < 45.0.2 |
24.0.1036.0.1144.0.345.0.2 |
How to fix
Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.
wasmtime-wasi crates.io → 24.0.10
- cargo
cargo update -p wasmtime-wasi --precise 24.0.10
Severity breakdown
CVSS 4.0 0.0
CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:L
- Attack vector
- Network
- Attack complexity
- Low
- Attack requirements
- Present
- Privileges required
- Low
- User interaction
- None
- Confidentiality (vulnerable system)
- None
- Integrity (vulnerable system)
- None
- Availability (vulnerable system)
- Low
- Confidentiality (subsequent systems)
- None
- Integrity (subsequent systems)
- None
- Availability (subsequent systems)
- Low
CVSS 3.1 5.0
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:L
- Attack vector
- Network
- Attack complexity
- Low
- Privileges required
- Low
- User interaction
- None
- Scope
- Changed
- Confidentiality
- None
- Integrity
- None
- Availability
- Low
Weakness
CWE-400: Uncontrolled Resource Consumption
The product does not properly control the allocation and maintenance of a limited resource.
How to prevent it
- Architecture and Design: Design throttling mechanisms into the system architecture. The best protection is to limit the amount of resources that an unauthorized user can cause to be expended. A strong authentication and access control model will help prevent such attacks from occurring in the first place. The login application should be protected against DoS attacks as much as possible. Limiting the database access, perhaps by caching result sets, can help minimize the resources expended. To further limit the potential for a DoS attack, consider tracking the rate of requests received from users and blocking requests that exceed a defined rate threshold.
- Architecture and Design: Mitigation of resource exhaustion attacks requires that the target system either: recognizes the attack and denies that user further access for a given amount of time, or uniformly throttles all requests in order to make it more difficult to consume resources more quickly than they can again be freed. The first of these solutions is an issue in itself though, since it may allow attackers to prevent the use of the system by a particular valid user. If the attacker impersonates the valid user, they may be able to prevent the user from accessing the server in question. The second solution is simply difficult to effectively institute -- and even when properly done, it does not provide a full solution. It simply makes the attack require more resources on the part of the attacker.
- Architecture and Design: Ensure that protocols have specific limits of scale placed on them.
- Implementation: Ensure that all failures in resource allocation place the system into a safe posture.
References
Advisories
Packages
Other links
- github.com/bytecodealliance/wasmtime/security/advisories/GHSA-3p27-qvp9-27qf
- github.com/bytecodealliance/wasmtime/pull/13650
- github.com/bytecodealliance/wasmtime/commit/100bfe27253d2ce5154ddddf66d06e30f3f…
- github.com/bytecodealliance/wasmtime/commit/36b305d827149ac0336ddcbc0a378c30333…
- github.com/bytecodealliance/wasmtime/commit/72493b11ed5df382c92a9dfb8b6bc064e47…
- github.com/bytecodealliance/wasmtime/commit/e9fbe974c9698edef117323d981e13caf20…
- github.com/bytecodealliance/wasmtime/commit/f069f125cb77a4a3dced19a77d737906106…
- github.com/bytecodealliance/wasmtime/releases/tag/v24.0.10
- github.com/bytecodealliance/wasmtime/releases/tag/v36.0.11
- github.com/bytecodealliance/wasmtime/releases/tag/v44.0.3
- github.com/bytecodealliance/wasmtime/releases/tag/v45.0.2
- rustsec.org/advisories/RUSTSEC-2026-0182.html
Timeline
- Published
- Last updated by the source
- Latest EPSS score
Related advisories
| Advisory | Severity | Why it's related |
|---|---|---|
| RUSTSEC-2026-0420 wasip3 UDP `send` can deliver a datagram to an address only allowed for receiving | Medium | Also affects wasmtime-wasi |
| RUSTSEC-2026-0352 Filesystem sandbox escape when renaming symlinks with trailing slashes | Not rated yet | Also affects wasmtime-wasi |
| RUSTSEC-2026-0324 Guest can panic host through filesystem timestamp before the epoch on wasip3 | Medium | Also affects wasmtime-wasi |
| RUSTSEC-2026-0321 WASI preview 0 implementation of `poll_oneoff` circumvents fuel consumption | Medium | Also affects wasmtime-wasi |
| RUSTSEC-2026-0323 fd_readdir copies uninitialized struct padding into guest memory | Low | Also affects wasmtime-wasi |
| RUSTSEC-2026-0322 Excessive allocated memory on the host when guests don't have stdio | Medium | Also affects wasmtime-wasi |
| RUSTSEC-2026-0314 Guest can panic host through filesystem datetime overflow | Medium | Also affects wasmtime-wasi |
| GHSA-4ch3-9j33-3pmj Wasmtime: WASI hard links bypass wasmtime-wasi's FilePerms for destination | Medium | Also affects wasmtime-wasi |
MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.
Check your repos with MergeHarbor