CVE-2026-58494: Wasmtime Privilege Escalation Vulnerability

CVE-2026-58494 Overview

CVE-2026-58494 affects Wasmtime, the reference runtime for WebAssembly maintained by the Bytecode Alliance. The vulnerability resides in the wasmtime-wasi crate, where hard-link creation and rename operations validate directory permissions but fail to compare the FilePerms of the source and destination preopens. A WASI guest holding a read-only file capability can leverage this gap to overwrite host files that were intentionally exposed as FilePerms::READ through the wasip1, wasip2, or wasip3 filesystem interfaces. The issue affects releases prior to 24.0.11, 36.0.12, 45.0.3, and 46.0.1.

Critical Impact
A sandboxed WebAssembly guest can bypass read-only file capability restrictions and overwrite host files across preopen boundaries, breaking a core WASI capability guarantee.

Affected Products

Wasmtime wasmtime-wasi versions prior to 24.0.11
Wasmtime wasmtime-wasi versions prior to 36.0.12
Wasmtime wasmtime-wasi versions prior to 45.0.3 and prior to 46.0.1

Discovery Timeline

2026-07-08 - CVE-2026-58494 published to NVD
2026-07-08 - Last updated in NVD database

Technical Details for CVE-2026-58494

Vulnerability Analysis

Wasmtime enforces filesystem isolation through preopens. Each preopen carries a DirPerms value that governs directory operations and a FilePerms value that governs file operations such as read and write. When a guest requests a hard link or rename that spans two preopens, the runtime must confirm that both endpoints share compatible permissions. The vulnerable code paths in crates/wasi/src/filesystem.rs, crates/wasi/src/host/filesystem.rs, and crates/wasi/src/p2/host/filesystem.rs only compared directory-level permissions. As a result, a guest with write access to one preopen and read-only access to another could create a hard link that effectively converted a read-only file into a writable target, then overwrite the host-side file. The weakness is classified as [CWE-281] Improper Preservation of Permissions.

Root Cause

The permission check omitted a comparison of FilePerms between the old directory and the new directory involved in hard_link and rename calls. Only DirPerms was validated, so mismatched file capabilities across preopens were silently accepted.

Attack Vector

Exploitation requires a locally executing WebAssembly module with legitimate access to at least two preopens: one writable and one exposed as read-only. The guest issues a hard_link or rename targeting a file in the read-only preopen using the writable preopen as the source directory handle. The runtime performs the operation because directory permissions align, and the host file is overwritten. No user interaction is needed.

rust

// Security patch in crates/wasi/src/filesystem.rs
         if old_path_flags.contains(PathFlags::SYMLINK_FOLLOW) {
             return Err(ErrorCode::Invalid);
         }
+        if self.perms != new_dir.perms || self.file_perms != new_dir.file_perms {
+            return Err(ErrorCode::NotPermitted);
+        }
         let new_dir_handle = Arc::clone(&new_dir.dir);
         self.run_blocking(move |d| d.hard_link(&old_path, &new_dir_handle, &new_path))
             .await?;
// Source: https://github.com/bytecodealliance/wasmtime/commit/5ddfd5f1ef28f2041fa07d237ad0336e167b0e0c

The patch adds an explicit equality check on both perms and file_perms before delegating to hard_link. Equivalent fixes were applied to the p2 host implementation in commit 7db94cd and to the release-24 branch in commit 8a250aa.

Detection Methods for CVE-2026-58494

Indicators of Compromise

Unexpected modifications to host files that were intended to be exposed as FilePerms::READ to WebAssembly guests.
Successful hard_link or rename WASI calls in application logs where source and destination preopens have mismatched file capabilities.
Wasmtime host process versions matching wasmtime-wasi releases earlier than 24.0.11, 36.0.12, 45.0.3, or 46.0.1.

Detection Strategies

Inventory all embedders of wasmtime-wasi and compare the linked crate version against the fixed releases published in the GitHub Security Advisory GHSA-4ch3-9j33-3pmj.
Instrument host applications to log every WASI hard_link and rename call along with the source and destination preopen identifiers for post-hoc review.
Use software composition analysis to flag vulnerable wasmtime and wasmtime-wasi dependencies in Rust Cargo.lock files.

Monitoring Recommendations

Enable filesystem integrity monitoring on directories passed to WebAssembly guests as read-only preopens.
Alert on any write, truncate, or rename event affecting files inside preopens configured with FilePerms::READ.
Track process execution of Wasmtime-based binaries and correlate with the crate versions declared at build time.

How to Mitigate CVE-2026-58494

Immediate Actions Required

Upgrade wasmtime and wasmtime-wasi to 24.0.11, 36.0.12, 45.0.3, or 46.0.1 depending on the release train in use.
Rebuild and redeploy every host application, service, or edge worker that statically links wasmtime-wasi.
Audit host code that grants asymmetric FilePerms across preopens and treat any observed cross-preopen hard_link or rename as suspect until patched.

Patch Information

The Bytecode Alliance released fixes in Wasmtime v24.0.11, Wasmtime v36.0.12, Wasmtime v45.0.3, and Wasmtime v46.0.1. The underlying code changes are documented in commits 5ddfd5f, 7db94cd, 8a250aa, and d3ceb56.

Workarounds

Where patching is not immediately possible, configure all preopens exposed to untrusted guests with identical FilePerms, eliminating the permission mismatch the bug relies on.
Do not expose sensitive host files through read-only preopens alongside a writable preopen granted to the same untrusted module.
Restrict which guests are permitted to invoke path_link and path_rename at the embedder layer until upgraded binaries are deployed.

bash

# Update Cargo.toml to a fixed release train, then rebuild
cargo update -p wasmtime --precise 46.0.1
cargo update -p wasmtime-wasi --precise 46.0.1
cargo build --release