CVE-2026-54786: Wasmtime File Descriptor Leak in fd_renumber Function

Technical summary

The vulnerability exists in Wasmtime's native implementation of WASIp1 (WebAssembly System Interface preview 1). The fd_renumber function is designed to reassign a file descriptor from one number to another, similar to the POSIX dup2 system call. Wasmtime's implementation updates the WASIp1-level descriptor table but does not close the original file descriptor in the host's operating system file table. This asymmetry causes the host to retain open file descriptors even though the guest perceives the renumbering as successful. Over multiple invocations in a loop, this leads to file descriptor table exhaustion and resource depletion on the host. The bug is confined to the native WASIp1 implementation and does not affect other WASI backends or interpreters that do not expose fd_renumber. Affected versions include all releases prior to 24.0.10, versions 25.0.0–36.0.10, versions 37.0.0–44.0.2, and versions 45.0.0–45.0.1.

Business impact

For organizations running Wasmtime as a service or embedding it in multi-tenant environments, this vulnerability enables guest WebAssembly modules to degrade or crash the host through resource exhaustion. In SaaS platforms or containerized deployments running untrusted WASM code, a malicious or compromised module can starve the host system of file descriptors, potentially affecting other guests or services. The impact is limited to availability (denial of service) with no confidentiality or integrity implications. Organizations that carefully restrict file access to WebAssembly guests or run only trusted code face reduced risk. The leakage is also gradual—each call to fd_renumber leaks resources over time rather than causing immediate failure—which may mask the attack until critical thresholds are reached.

Affected systems

The vulnerability affects Wasmtime versions: prior to 24.0.10; versions 25.0.0 through 36.0.10; versions 37.0.0 through 44.0.2; and versions 45.0.0 and 45.0.1. Only runtimes that (1) expose the native WASIp1 implementation, (2) allow WebAssembly modules to call fd_renumber, and (3) permit guest modules to open or access file descriptors are affected. Runtimes that deny file access to guests, use alternative WASI implementations, or disable fd_renumber are not vulnerable. Any embedded application, container runtime, or serverless platform using the affected Wasmtime versions with permissive file descriptor policies is at risk.

Exploitability

Exploitation requires authenticated access—the attacker must be able to load and execute WebAssembly code within the Wasmtime runtime and must have permission to acquire file descriptors. The attack is trivial to execute: a simple loop calling fd_renumber with valid file descriptors will exhaust host resources. No complex exploit chains, race conditions, or memory corruption techniques are needed. The barrier to exploitation is primarily administrative: preventing untrusted code execution or restricting file descriptor access mitigates the risk. The CVSS score of 5.0 (Medium) reflects the need for prior authentication and the availability-only impact; however, in multi-tenant or service environments where guest code execution is the business model, the practical risk is higher.

Remediation

Upgrade Wasmtime to patched versions: 24.0.10 or later (for the 24.x series), 36.0.11 or later (for 25.x–36.x), 44.0.3 or later (for 37.x–44.x), or 45.0.2 or later (for 45.x). The patches correct the fd_renumber function to properly close the old file descriptor in the host's file table. Verify the exact patch versions against official Bytecode Alliance release notes. Organizations unable to patch immediately should restrict file descriptor access for guest modules or disable fd_renumber if operationally feasible.

Patch guidance

Update Wasmtime to the earliest patched version in your release series: 24.0.10, 36.0.11, 44.0.3, or 45.0.2. Consult the Bytecode Alliance release notes and migration guides for each version to ensure no breaking changes affect your deployment. Test patches in a staging environment before rolling out to production, particularly if you rely on fd_renumber functionality. After patching, monitor for any performance improvements in file descriptor usage and verify that guest modules continue to function as expected.

Detection guidance

Monitor the host system's file descriptor count (via /proc/sys/fs/file-nr on Linux or lsof commands) during Wasmtime workload execution. A steady increase in open file descriptors that does not correlate with legitimate guest activity may indicate exploitation. Implement resource limits per Wasmtime Store or container (ulimit, cgroups) to cap file descriptor usage and prevent system-wide exhaustion. Log fd_renumber calls if instrumentation is available, and alert on unusually high call frequencies from individual guests. Correlate file descriptor leaks with guest module execution patterns to identify suspicious behavior.

Why prioritize this

This vulnerability merits prompt patching due to its simplicity of exploitation and the common multi-tenant deployment model of WebAssembly runtimes. However, the Medium CVSS score and the requirement for authenticated access and file descriptor permissions limit its absolute priority compared to unauthenticated remote code execution vulnerabilities. Prioritize patching if you (1) run Wasmtime in a multi-tenant environment, (2) execute untrusted guest code, or (3) grant file access to guests. Organizations with strict file descriptor policies or running only trusted code may defer patching with appropriate risk acceptance. The gradual nature of the leak allows time for planned updates rather than emergency response.

Risk score, explained

The CVSS 3.1 score of 5.0 (Medium) is driven by: Attack Vector = Network (the vulnerability is reachable over the network if Wasmtime is exposed), Attack Complexity = Low (trivial to exploit), Privileges Required = Low (authenticated access needed), User Interaction = None, Scope = Changed (the impact extends beyond the vulnerable component to the host system), Confidentiality = None, Integrity = None, and Availability = Low (denial of service through resource exhaustion). The score accurately reflects that this is a moderate, availability-focused issue requiring prior access. In threat modeling, organizations should consider elevation of risk if they operate multi-tenant WASM environments or run untrusted code.

Frequently asked questions