CVE-2026-47261: Wasmtime Filesystem Permission Bypass via TRUNCATE Flag

Technical summary

The vulnerability is rooted in Wasmtime's WASI (WebAssembly System Interface) filesystem implementation, specifically in crates/wasi/src/filesystem.rs within the Dir::open_at function. When processing the OpenFlags::TRUNCATE flag during file operations via wasip2 descriptor.open-at or wasip1 path_open interfaces, the code fails to set the OpenMode::WRITE bit before performing access control validation against FilePerms. This allows a caller with only read permissions to open a file with TRUNCATE intent, which truncates (and effectively modifies) the file's contents. The fix is a single-line addition that ensures OpenMode::WRITE is set when TRUNCATE is requested, causing subsequent permission checks to correctly reject the operation with ERRNO_PERM. The vulnerability is classified under CWE-284 (Improper Access Control).

Business impact

Organizations embedding Wasmtime with restrictive filesystem permissions face a degradation of their security model. If a WASM module is intentionally confined to read-only access to protect sensitive files or configuration data, a malicious or compromised module can truncate those files, leading to data destruction, configuration corruption, or denial of service. The practical impact depends on the trust model: sandboxed untrusted WASM code becomes a more significant risk. However, the Wasmtime CLI itself is not affected, limiting exposure in that common deployment scenario.

Affected systems

Vulnerable versions are Wasmtime prior to 24.0.9 (1.x branch), 36.0.10 (36.x branch), and 44.0.2 (44.x branch). Only embeddings that combine DirPerms::MUTATE (directory mutation allowed) with FilePerms::READ (file read-only) for filesystem preopens are affected. Direct users of wasmtime-cli are not vulnerable because it defaults to FilePerms::all(). Custom embeddings that implement granular permission models are at risk.

Exploitability

Exploitation requires the attacker to control the WebAssembly code execution within a Wasmtime instance configured with the vulnerable permission combination. No network access is required; the attack is local to the WASM runtime. It is straightforward to trigger once the preconditions are met—simply issuing a file open with the TRUNCATE flag against a read-only file is sufficient. The barrier to exploitation is primarily the deployment scenario (intentional restriction of WASM permissions combined with untrusted module execution).

Remediation

Upgrade to patched versions: Wasmtime 24.0.9 or later, 36.0.10 or later, or 44.0.2 or later. Verify your version via wasmtime --version and update your dependency in Cargo.toml or your build system accordingly. After patching, verify that affected WASM modules can no longer bypass permission constraints.

Patch guidance

Apply updates from the Bytecode Alliance's official Wasmtime release channels. Check your current version and update to the next available patch in your release branch (24.x, 36.x, or 44.x). For production systems, test the patched version in a staging environment first to ensure compatibility with your WASM workloads. Consult the official Wasmtime release notes and security advisories for validation of patch integrity.

Detection guidance

Monitor for Wasmtime version numbers in your supply chain and runtime inventories. If you maintain custom embeddings, audit your filesystem preopen configurations: search for instances where DirPerms::MUTATE is paired with FilePerms::READ. Check Wasmtime initialization code and configuration files for these patterns. Additionally, monitor WASM module behavior for suspicious file truncation attempts (e.g., TRUNCATE operations on files that should be read-only in your policy).

Why prioritize this

This vulnerability merits immediate attention for any organization running custom Wasmtime embeddings with restrictive filesystem permissions. The HIGH CVSS score (7.5) reflects the integrity impact and ease of exploitation once preconditions are met. While default deployments are unaffected, the attack is straightforward and can lead to data destruction. Prioritize patching if you use Wasmtime outside of the standard CLI and enforce permission boundaries on untrusted WASM code.

Risk score, explained

The CVSS 3.1 score of 7.5 (HIGH) is driven by: high integrity impact (ability to modify protected files via truncation), network-accessible attack vector, low complexity, no privilege requirement, and no user interaction. However, the score assumes the vulnerable configuration is in use; organizations using Wasmtime CLI or with FilePerms::all() have zero risk. The severity is bounded by the requirement that the attacker must already control WASM code execution, limiting the attack surface.

Frequently asked questions