CVE-2026-115392 in Wasmtime
Summary
by MITRE • 10/22/2026
Wasmtime before 24.0.13, 25.0.0 before 36.0.14, 37.0.0 before 46.0.3, and 47.0.0 before 47.0.4 allows a filesystem sandbox escape in wasmtime-wasi because its cap-std dependency mishandles symlinks with trailing slashes on macOS and Linux kernels lacking openat2. A guest with write access to any sandboxed directory can read and write any host-accessible file, and read-only guests may read host files via preexisting symlinks.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/22/2026
The vulnerability identified in Wasmtime versions prior to 24.0.13, 25.0.0 through 36.0.14, 37.0.0 through 46.0.3, and 47.0.0 through 47.0.4 represents a critical failure in the WebAssembly System Interface implementation, specifically within the wasmtime-wasi component. This flaw stems from an improper handling of symbolic links that contain trailing slashes by the underlying cap-std dependency library. The security boundary intended to isolate guest execution environments from the host operating system is compromised because the filesystem sandboxing logic fails to correctly resolve or validate these specific path structures on macOS and Linux systems that do not support the openat2 syscall with its associated flags for secure file access resolution.
From a technical perspective, the core issue lies in how the runtime processes directory paths ending with a slash character when interacting with symbolic links. In standard POSIX-compliant environments utilizing modern kernel features like openat2, such operations are typically handled securely by preventing traversal outside of designated sandbox boundaries. However, on systems lacking this specific syscall support or where fallback mechanisms are employed, the path resolution logic incorrectly interprets trailing slashes in symlink targets. This misinterpretation allows the virtualized filesystem layer to bypass directory restrictions that should otherwise contain file access within the defined sandbox perimeter. The flaw effectively neutralizes the containment guarantees provided by WebAssembly's sandboxing model for any operation involving these specific symbolic link configurations.
The operational impact of this vulnerability is severe, as it enables a complete escape from the guest environment into the host filesystem. For guests that possess write permissions to even a single directory within the sandboxed area, an attacker can read and modify arbitrary files accessible by the host process running Wasmtime. This level of access allows for data exfiltration, modification of critical system or application configuration files, and potentially further exploitation vectors depending on the privileges of the host process. Even in scenarios where the guest is restricted to read-only operations within its sandbox, an attacker can still exploit preexisting symbolic links that point outside the sandbox boundary to read sensitive host files. This means that even without write capabilities, the confidentiality of data stored on the host machine is compromised if such symlinks exist and are accessible through the vulnerable path resolution logic.
This vulnerability aligns with CWE-20 Improper Input Validation, as the system fails to adequately validate or sanitize input paths involving symbolic links with trailing slashes before processing them against sandbox boundaries. Furthermore, it maps directly to MITRE ATT&CK technique T1564.003 Sandbox Escape: File System Exfiltration and T1564.002 Sandbox Escape: Dynamic Linker Hijacking if the escaped access is leveraged to modify dynamic linking configurations. The attack vector typically involves crafting specific WebAssembly modules that invoke filesystem operations targeting these malformed or specifically structured symbolic links, thereby triggering the flawed resolution logic in the cap-std dependency.
Mitigation for this issue requires immediate upgrading of Wasmtime to version 24.0.13 or later, 25.0.0 through 36.0.14 and beyond, 37.0.0 through 46.0.3 and beyond, and 47.0.0 through 47.0.4 and beyond. These updated versions contain patches that correct the symlink handling logic to ensure consistent behavior across different operating systems and kernel capabilities. In environments where upgrading is not immediately feasible, administrators should audit host filesystem configurations to remove or restrict access to any symbolic links that point outside of designated sandbox directories. Additionally, restricting guest permissions to read-only modes can mitigate data modification risks, although it does not fully prevent information disclosure via existing external symlinks. Implementing strict file system policies and monitoring for unusual path traversal attempts in WebAssembly workloads is also recommended as a defense-in-depth measure until the software stack is updated.