Advisory · CVE-2026-115392
Wasmtime filesystem sandbox can be escaped with trailing-slash symlinks on macOS and older Linux kernels
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 inherits a cap-std flaw where symlinks with trailing slashes escape the filesystem sandbox on macOS and Linux kernels without openat2, letting guests read and write host files. CVSS 4.0 8.8.
- Vendor
- Bytecode Alliance
- Product
- Wasmtime
- Identifier / CWE
- CVE-2026-115392
CWE-61 - Action timing
- Immediate
Explain it like I’m five
The sandbox fence checks every path a guest touches, but a shortcut whose name ends in a slash slips past the checker on some operating systems, and through that gap the guest can reach the whole host filesystem.
- 01Guest gets a sandboxed directory
A guest is granted access to a directory inside its filesystem sandbox, with write access, or read-only access where symlinks already exist in the directory.
- 02Trailing slash defeats the check
Per the Wasmtime advisory, its cap-std dependency mishandles symlinks when a trailing slash is used in specific circumstances, on systems where the openat2 based resolution is unavailable.
- 03Path resolves outside the sandbox
The guest uses a symlink with a trailing slash to reach directories and files outside the preopened sandbox directory.
- 04Host files are reached
Guests with write access to any sandboxed directory can read and write any file the host process can access, and read-only guests may read host files through preexisting symlinks.
What happened
The Bytecode Alliance disclosed CVE-2026-115392 in its Wasmtime security advisory: the filesystem implementation in the wasmtime-wasi crate contained a bug that allowed guests to escape their filesystem sandbox and read or write external files and directories. Wasmtime states its filesystem sandboxing is primarily provided by the cap-std family of crates, and that dependency had a vulnerability which meant that when dealing with symlinks, a trailing slash could be used in specific circumstances to escape the filesystem sandbox. The CVE record lists 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 as affected. The CVSS 4.0 score is 8.8 and the CVSS 3.1 score is 7.9, with changed scope.
Per the advisory, this is a full filesystem sandbox escape for guests. The cap-std bug does not affect users on a Linux kernel after 5.6 with the openat2 syscall, where cap-std uses a resolution flag that is not affected; users on macOS or older Linux kernels are affected. Wasmtime 24.0.13, 36.0.14, 46.0.3 and 47.0.4 are released with the patch, and the advisory states the 48.0.0 release and later are not affected. Wasmtime states there is no known workaround, and recommends upgrading to a patch release that contains a fixed wasmtime-wasi.
What to do
- Inventory applications and services that embed Wasmtime with WASI filesystem access, and note the Wasmtime version and the host operating system and kernel of each.
- Prioritize macOS hosts and Linux hosts on kernels without openat2 support, which the advisory identifies as affected; Linux hosts on kernels after 5.6 using openat2 are not affected by this bug per the advisory.
- Upgrade affected embeddings to Wasmtime 24.0.13, 36.0.14, 46.0.3 or 47.0.4 or later for the branch in use, or to 48.0.0 or later; the advisory states there is no known workaround.
- Until upgraded, avoid granting untrusted guests write access to sandboxed directories, and review preopened directories for symlinks guests could abuse.
- Look for guest access to files outside preopened directories, and verify the deployed version in every embedding after updating.
Management note
A WASI preopen is supposed to be a hard filesystem boundary. On macOS and older kernels it was not, so inventory by host platform matters here: the same Wasmtime version is exposed on one fleet and unaffected on another.