CVE-2026-54786: Host File Descriptor Exhaustion in Wasmtime WASIp1 Runtime

The WebAssembly System Interface (WASI) Preview 1 (WASIp1) provides WebAssembly guest modules with standardized access to host operating system resources, such as filesystems and sockets. Within this framework, the fd_renumber system call is designed to atomically replace a guest virtual file descriptor (from) with another virtual file descriptor (to). This behavior mimics POSIX-standard operations like dup2, which require that if the target file descriptor is currently open, it must be closed before the renumbering or duplication is completed.

Wasmtime's native implementation of WASIp1, found within the wasmtime-wasi crate, failed to enforce this implicit close requirement on the host operating system level. While the virtual descriptor table mapping within the guest state was updated correctly, the underlying host file descriptor representing the target was left open. This architectural gap created a structural mismatch between the host-level operating system tables and Wasmtime's internal state.

The attack surface for this vulnerability is restricted to environments that execute arbitrary, untrusted WebAssembly code with file or directory access privileges. If the host application configures the Wasmtime runtime to allow file operations (such as through preopened directories), a guest module can repeatedly trigger this state discrepancy to leak file handles on the host operating system. Conversely, runtimes that completely block file access are immune to this specific vector.

The root cause of CVE-2026-54786 lies in the omission of resource cleanup operations during virtual file descriptor remapping. In wasmtime-wasi, the state of opened file descriptors is tracked within a guest-facing lookup table (st.descriptors.used), which maps guest-facing integers (descriptors) to host-facing structures representing file system resources. When the guest executed fd_renumber(from, to), Wasmtime modified only this guest-facing virtual map by deleting the entry at from and inserting it at to.

However, prior to the patch, Wasmtime's implementation did not verify whether the destination descriptor (to) was already associated with an active host-level file handle. If the target slot (to) was occupied, the corresponding reference within st.descriptors.used was overwritten, removing the guest's capability to access or close that file descriptor. Since the guest could no longer refer to the overwritten handle, it was impossible to invoke a standard close operation on it from within the virtual machine context.

Crucially, the physical file descriptor allocated by the host operating system was not closed. In Rust, file resources are tied to the lifetime of their containing structures; since Wasmtime's internal state tracking lost the handle without dropping the underlying OS resource, the host file descriptor remained allocated within the kernel's file table. These leaked file descriptors persist until the parent Store and its associated WASI state context are destroyed, which in long-lived or multi-tenant hosting environments may never occur or may occur only after considerable delay.

To understand the technical structure of the vulnerability, we analyze the vulnerable implementation of fd_renumber in crates/wasi/src/p1.rs. The pre-patch function was executed synchronously and directly manipulated the internal WasiState structure:

// Vulnerable Implementation
fn fd_renumber(
    &mut self,
    _memory: &mut GuestMemory<'_>,
    from: types::Fd,
    to: types::Fd,
) -> Result<(), types::Error> {
    let mut st = self.transact()?;
    let from = from.into();
    let to = to.into();
    if !st.descriptors.used.contains_key(&to) {
        return Err(types::Errno::Badf.into());
    }
    // Vulnerability: The entry for 'to' is overwritten without closing 
    // the host operating system file descriptor.
    let btree_map::Entry::Occupied(desc) = st.descriptors.used.entry(from) else {
        return Err(types::Errno::Badf.into());
    };
    if from != to {
        let desc = desc.remove();
        st.descriptors.free.insert(from);
        st.descriptors.free.remove(&to);
        st.descriptors.used.insert(to, desc);
    }
    Ok(())
}

In the patched implementation, the function is refactored to be asynchronous (async fn fd_renumber), allowing it to perform the non-blocking close operation (self.fd_close(memory, to_fd).await?) before executing the table swap. This ensures that the destination descriptor is cleanly terminated on both the virtual and host levels before its slot is occupied by the source descriptor.

// Patched Implementation (Commit e9fbe974c9698edef117323d981e13caf2097c13)
async fn fd_renumber(
    &mut self,
    memory: &mut GuestMemory<'_>,
    from_fd: types::Fd,
    to_fd: types::Fd,
) -> Result<(), types::Error> {
    let from = from_fd.into();
    let to = to_fd.into();
    {
        // Scope transaction lock to check key existence
        let st = self.transact()?;
        if !st.descriptors.used.contains_key(&to) || !st.descriptors.used.contains_key(&from) {
            return Err(types::Errno::Badf.into());
        }
        if from == to {
            return Ok(());
        }
    } // Transaction lock 'st' is dropped here to avoid borrow conflicts during await
    
    // Explicitly close the destination file descriptor prior to remapping
    self.fd_close(memory, to_fd).await?;
    
    // Re-acquire the transaction lock to update the virtual tables safely
    let mut st = self.transact()?;
    let btree_map::Entry::Occupied(desc) = st.descriptors.used.entry(from) else {
        return Err(types::Errno::Badf.into());
    };
    let desc = desc.remove();
    st.descriptors.free.insert(from);
    st.descriptors.free.remove(&to);
    st.descriptors.used.insert(to, desc);
    Ok(())
}

This patch resolves the resource leak by strictly decoupling the state check, the host resource disposal, and the subsequent map manipulation. By dropping the first transaction reference prior to executing fd_close, Wasmtime avoids borrow-checker conflicts and concurrency deadlocks that would arise from holding state locks across asynchronous boundaries.

Exploitation of this vulnerability requires that a malicious WebAssembly guest has permission to perform file system operations. Specifically, the host must preopen at least one directory, giving the guest module a starting file descriptor to open additional files. From this position, the guest can systematically exhaust host process file descriptors by executing a tight loop of file-opening and renumbering calls.

The core mechanics of the exploit involve repeatedly calling path_open to obtain a new source file descriptor (from), and then calling fd_renumber to overwrite a static destination descriptor (to). For each iteration of the loop, the guest opens a file, resulting in descriptor N. It then renumbers descriptor N to descriptor M (where M is already open). Because the host descriptor underlying M is never closed, one physical file descriptor leaks into the host process memory space.

This technique is highly reliable because it does not depend on complex memory corruption or probabilistic race conditions. It is a logic flaw that executes with 100% deterministic success. Wasmtime's integrated regression test test_renumber_loop demonstrates that executing this sequence 2,000 times is sufficient to rapidly exceed typical operating system resource limits (such as RLIMIT_NOFILE), forcing all subsequent socket or file allocations in the host process to fail immediately.

The primary impact of CVE-2026-54786 is a Denial of Service (DoS) affecting the host process executing the Wasmtime runtime. When the host process exhausts its available file descriptors, it can no longer open new database connections, accept incoming TCP connections, write to log files, or load shared libraries. In multi-tenant platforms where a single host process handles guest workloads for multiple users, a single malicious tenant can degrade or crash the service for all other tenants.

The vulnerability is rated as Medium severity (CVSS v3.1: 5.0) because the scope of the impact is typically restricted to process termination or localized service interruption. It does not directly permit remote code execution (RCE) on the host, nor does it allow a guest to bypass filesystem path isolation boundaries or read unauthorized host files. The risk is classified with a 'Changed' scope (S:C) because the resource depletion occurring within the virtualized guest sandbox propagates outward to affect the physical host OS environment.

In environments operating high-availability cloud-native services, file descriptor exhaustion can lead to cascade failures. If health-check endpoints within the host process require file descriptor allocation to process incoming requests, the load balancer may mark the entire instance as unhealthy, triggering container restarts and service instability. Therefore, although categorized as Medium severity, the operational impact in enterprise deployments can be substantial.

Remediation requires upgrading the Wasmtime runtime to a patched release. The Bytecode Alliance has backported fixes to all actively supported release streams, including versions 24.0.10, 36.0.11, 44.0.3, and 45.0.2. Development teams must update their Cargo dependencies to pull these specific versions or higher to ensure the native WASIp1 implementation is secured.

If immediate patching is not possible, security teams can apply temporary operational mitigations. The vulnerability can be neutralized by denying guests permission to open files or access directories. Since the leak requires acquiring new file handles to trigger the renumber loop, removing directory preopens or disabling virtual filesystem capabilities entirely prevents exploitation of the flaw.

Detection of exploit attempts should focus on host-level monitoring of resource metrics. Security administrators can monitor open file descriptor counts per process on Linux systems by examining the /proc/<pid>/fd/ directory. A sudden, non-linear increase in the number of open file descriptors associated with the Wasmtime host process, particularly those referencing identical path targets or pipes, serves as a strong indicator of an active exploitation attempt or a severe runtime resource leak.