CVE-2026-47261: Wasmtime Flaw Bypasses Filesystem Sandboxing

A high-severity vulnerability in Wasmtime, a leading WebAssembly runtime, allows sandboxed code to bypass filesystem permissions. Tracked as CVE-2026-47261, the flaw enables a WebAssembly module to write to files that are configured as read-only. This breaks a fundamental security promise of the sandbox, with direct implications for applications that run untrusted code.

A Flaw in the Sandbox Wall

WebAssembly runtimes like Wasmtime provide isolated environments for executing code. This sandboxing is critical for agentic architectures, which often use autonomous agents to run tools or process data from untrusted sources. The security of the entire system depends on the integrity of this sandbox.

This vulnerability undermines that integrity. An attacker can craft a WebAssembly module that, when run in a specifically configured host environment, can modify or delete files it should only be able to read. This could lead to data corruption, unauthorized configuration changes, or denial of service.

The Attack Explained

The exploit is not universally applicable. It requires a specific, and likely uncommon, host configuration. The vulnerability manifests when a pre-opened directory is mounted with permissions to modify the directory itself, but not the files within it. This is expressed as `DirPerms::MUTATE` combined with `FilePerms::READ`. [1]

With this condition met, a malicious module can call the `path_open` function with the `OFLAGS_TRUNC` flag. This flag tells the system to truncate the file if it exists. Due to the bug, this operation was permitted even without write permissions, leading to a permission bypass. A correct implementation would deny this request. [2]

Technical Root Cause

The flaw was a subtle logic error in the `Dir::open_at` function within Wasmtime's WASI implementation. The code path that handled the `OpenFlags::TRUNCATE` flag correctly set internal options to perform a truncation. However, it failed to update a separate variable used for the final access control check.

Specifically, the code did not add the `OpenMode::WRITE` flag to the `open_mode` variable when truncation was requested. Later, the permission check consulted this variable, saw no write flag, and incorrectly approved the operation. A single line of code to set the write flag was all that was needed to fix the bug.

Implications for Agentic Architectures

Agentic systems rely on sandboxing as a non-negotiable security boundary. They are designed to execute tools, plugins, or arbitrary code snippets as part of their operation. Wasmtime is a popular choice for this task due to its performance and strong security guarantees.

A flaw like CVE-2026-47261 demonstrates the fragility of this trust. An AI agent could be manipulated into running a malicious Wasm module, perhaps disguised as a legitimate tool. This module could then exploit the vulnerability to break its containment, potentially modifying its own operating instructions or corrupting shared data used by other parts of the system.

The potential for damage is high. An exploited agent could tamper with its knowledge base, poison training data it is supposed to analyze, or alter system configurations. The host system would be blind to this activity, assuming the agent is still operating within its secure sandbox.

Scope of a Specific Flaw

It is important to note the specific conditions required for this exploit. Most users of wasmtime-wasi are not vulnerable. The flaw only affects those who use the precise combination of directory and file permissions that allow directory mutation but restrict file writes.

Ironically, the Wasmtime project's own command-line tool, `wasmtime-cli`, is not affected. This is because it grants full file permissions for all pre-opened directories by default. This permissive setting inadvertently sidesteps the logic bug, highlighting the subtle and configuration-dependent nature of the vulnerability.

Remediation and Mitigation

The Bytecode Alliance, the maintainers of Wasmtime, have released patches to address the vulnerability. The primary mitigation is to update to a fixed version. Patches are available for multiple release branches to support a wide range of users.

For users on the 24.x release branch, version 24.0.9 contains the necessary security fix. [3]

Developers using the 36.x branch of Wasmtime should update to version 36.0.10 to resolve the issue. [4]

The vulnerability is also patched in version 44.0.2 for teams using the 44.x release line. [5]

The most recent stable release, version 45.0.0, also incorporates the correction for this flaw. [6]

In addition to patching, security teams should audit their applications for use of the `WasiCtxBuilder`. This will help identify any instances of the vulnerable permission configuration. The Rust Security Advisory Database also lists this issue as RUSTSEC-2026-0149. [7]