Skip to content
secopssignal
Thursday, October 22, 2026Tech and security news that matters229 reports
Vulnerabilities

Wasmtime symlink bug enables cap-std sandbox escape for host file access

A CVE-2026-115392 vulnerability in Wasmtime allows guest processes to bypass filesystem restrictions and access host files on specific operating systems.

Illustration: A sleek computer chip sits on a circuit board, with a thin wire looped like a symlink connecting it to an open folder outside its designated boundary.
AI-generated illustration: SecOps Signal

Key points

  • The flaw allows sandbox escape via symlink mishandling in the cap-std dependency.
  • Affected versions include Wasmtime before 24.0.13 and 37.0.0 before 46.0.3.
  • The issue is rated CVSS 8.8 HIGH by the National Vulnerability Database.

The Bytecode Alliance’s Wasmtime runtime contains a filesystem sandbox escape vulnerability that permits unauthorized access to host files. According to the National Vulnerability Database, this flaw affects Linux and macOS environments where the underlying kernel lacks openat2 support or where symlink handling is imperfect.

The defect resides within the wasmtime-wasi component, specifically in how its cap-std dependency processes symbolic links that include trailing slashes. This misconfiguration allows a guest process with write permissions to a sandboxed directory to read and write any file accessible to the host system. Even guests with read-only access can potentially read host files by leveraging preexisting symlinks.

The risk

The National Vulnerability Database assigns CVE-2026-115392 a CVSS score of 8.8, classifying it as a high-severity vulnerability. The core weakness is identified as CWE-61, which relates to improper handling of symbolic links. In a secure sandbox environment, guest processes should be strictly confined to designated directories.

This flaw breaks that confinement by allowing the runtime to follow symlinks outside the intended boundary. Consequently, an attacker who controls the guest workload can traverse the filesystem hierarchy. They can target sensitive configuration files, credentials, or application data stored on the host machine, bypassing the isolation guarantees that Wasmtime is designed to provide.

Who is exposed

Multiple version branches of Wasmtime are affected by this vulnerability. According to the NVD record, Wasmtime versions before 24.0.13 are vulnerable. Users of the 25.0.0 branch are exposed until version 36.0.14. The 37.0.0 branch remains at risk until version 46.0.3. Additionally, the 47.0.0 branch is affected before version 47.0.4. Organizations running any of these older releases on Linux or macOS systems are potentially exposed. The risk is present in any deployment where Wasmtime is used to execute untrusted or third-party WebAssembly modules, as the sandbox boundary can be breached to reach the host filesystem.

Cost and compliance

The source material does not report any confirmed financial losses, data breaches, or specific compliance violations resulting from this vulnerability. The National Vulnerability Database record focuses solely on the technical classification and affected versions. There is no mention of active exploitation in the wild or any regulatory penalties incurred by organizations running vulnerable Wasmtime instances. The severity rating reflects the potential impact of the flaw rather than observed consequences.

What to watch

Security teams should verify their current Wasmtime versions against the vulnerable ranges listed in the NVD record. Monitor for unexpected file access patterns from WebAssembly guest processes, particularly those involving symbolic links. Ensure that host filesystem permissions are restrictive, limiting what the Wasmtime runtime user account can access even if the sandbox is bypassed.

Signals worth monitoring

Teams usually review file access logs for guest processes attempting to read or write outside their designated directories. Check whether symbolic links are being resolved to paths outside the sandbox root. Look for alerts indicating that a containerized or sandboxed workload is accessing sensitive host configuration files. Monitor for unusual system calls related to file traversal, especially on systems lacking openat2 support. Investigate any guest process that successfully reads files it should not have permission to access.

What to do and how to stay safe: Wasmtime

  • Audit your Wasmtime installations to identify versions prior to 24.0.13, 36.0.14, 46.0.3, or 47.0.4.
  • Restrict the host filesystem permissions for the user account running the Wasmtime runtime.
  • Monitor system logs for guest processes accessing files outside their sandboxed directories.
  • Plan to upgrade to patched versions once the vendor provides an update for your specific branch.

Step-by-step guide: Vulnerability Prioritization: Fix What Actually Matters First

General security guidance from the SecOps Signal newsroom. It is not confirmed advice from the organisations named in this story.

Frequently asked questions

Which Wasmtime versions are affected by CVE-2026-115392?

Versions 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 are affected.

What is the CVSS score for this vulnerability?

The National Vulnerability Database rates CVE-2026-115392 as CVSS 8.8, which is classified as high severity.

How does the sandbox escape occur?

It occurs because the cap-std dependency mishandles symlinks with trailing slashes on macOS and Linux kernels lacking openat2.

Sources

  1. CVE Program
WasmtimeCVE-2026-115392Bytecode Alliancesandbox escapesymlink

Related stories