RustSec flags Wasmtime WASI bug that can bypass file write limits

A sandboxed WebAssembly guest could still truncate a host file even when Wasmtime was supposed to deny write access. That is the boundary RustSec’s latest high-severity advisory puts under a microscope: a WASI path_open flaw that let write limits be bypassed through a code path tied to TRUNCATE.

RustSec issued RUSTSEC-2026-0149 on May 22, 2026, after the report came in on May 21. The issue carries CVE-2026-47261 and a CVSS v3.1 score of 7.5 High, with the vector AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N. The problem lives in wasmtime-wasi, not the core Wasmtime runtime, and it matters because the crate is the host-side layer that exposes WASI capabilities inside Wasmtime.

The vulnerable case appears when a filesystem preopen is configured with DirPerms::all() and FilePerms::READ without FilePerms::WRITE. In that setup, an untrusted guest could use either the wasip2 descriptor.open-at interface or the wasip1 path_open interface, supplying OpenFlags::TRUNCATE or OFLAGS_TRUNC, and reach a truncation path that should have been blocked. The root cause was narrow but serious: the TRUNCATE branch did not set open_mode |= OpenMode::WRITE before the permission check, so the later access-control logic failed to treat truncation as a write-like operation.

The impact is integrity-focused. A guest could modify data where write access should have been denied, which is exactly the kind of policy failure WASI is meant to prevent. RustSec marked the advisory network-reachable, low-complexity, with no privileges required and no user interaction required, making it especially relevant for server-side embeddings that run plugins, multi-tenant workloads, or other untrusted code.

Not every Wasmtime deployment is exposed. The Wasmtime project says wasmtime-cli is not affected because it always sets FilePerms::all() for preopens. The vulnerable surface is the embedding pattern that combines DirPerms::MUTATE with FilePerms::READ, while assuming the host filesystem policy will continue to block writes.

Fixes are already lined up in patched releases: 24.0.9, 36.0.10, 44.0.2, and 45.0.0. The GitHub advisory says corrected calls now fail with error-code.not-permitted and ERRNO_PERM. That patch set arrives in the middle of Wasmtime’s monthly cadence, where major versions are released on the 20th of each month, after 44.0.0 landed on April 20, 2026 and 44.0.1 followed on April 30. For anyone treating WASI preopens as a security boundary, this is the kind of bug that turns a read-only contract into a truncation primitive.