RustSec flags Wasmtime WASI flaw that bypasses file permissions

RustSec on June 29 issued RUSTSEC-2026-0188 for Wasmtime's WASI filesystem, a medium-severity flaw with a CVSS score of 6.5 that was reported on June 24. A WASI guest could take a file exposed as read-only through one preopen, hard-link it into another preopen that allowed writes, and then overwrite the host file; renaming a hard link into a writable preopen could trigger the same bypass. The issue reached through the wasip1, wasip2, and wasip3 interfaces.

That cuts into the trust model Rust developers often attach to WasiCtxBuilder's preopened_dir and its file_perms setting. Wasmtime documents file_perms as the maximum permissions usable for files in a preopen, and says those filesystem permissions are enforced before the underlying operating system gets involved. The assumption many sandbox authors made was simple: if a file entered a WASI guest as read-only, FilePerms would hold that line. This advisory shows that hard-link and rename behavior could move the same host object into a different permission context and defeat the destination-path check.

The affected wasmtime-wasi ranges are below 24.0.11, 36.0.12, 45.0.3, and 46.0.1, with fixes landing in 24.0.11, 36.0.12, 45.0.3, and 46.0.1. The GitHub Security Advisory, GHSA-4ch3-9j33-3pmj, describes the failure as a guest with read-only source-file capability still being able to modify that file if it could reach the same object through a writable preopen. In other words, the bug was not a broad failure of WASI isolation, but a very specific collapse of the permission boundary around filesystem identity.

For operators using Wasmtime as an app sandbox, plugin host, or serverless runtime, the immediate move is to upgrade to a patched release and then audit every preopened directory pairing. Any setup that exposes the same underlying host file through both read-only and writable preopens deserves a fresh review, because the advisory shows that a path label is not the same thing as an inode boundary. Hard links and renames were enough to punch through the mental model; patched versions close that gap, but only if the deployment stops assuming FilePerms alone can police every filesystem transition.