Wasmtime EUVD-2026-112393

Three concrete conditions must all hold. (1) The host operating system must be macOS or FreeBSD - Linux and Windows are explicitly not affected because their renameat does not follow a symlink with a trailing slash. (2) The embedding application must run an affected wasmtime-wasi version (<=36.0.17, 37.0.0 through 48.0.5, or 49.0.0 through 49.0.2) and must have granted the guest write access to at least one directory within its sandbox. (3) The guest must be able to create a symlink and issue a rename - and only symlinks pointing to directories can be used to escape. Limiting factors: the attacker must already be executing as a guest inside the sandbox (not a wholly external/unauthenticated actor), the host-OS restriction excludes the common Linux/Windows server case, and only directory symlinks work; no end-user interaction is required once a malicious guest runs.

This is a full filesystem sandbox escape in wasmtime-wasi rated CVSS 4.0 8.8, and the technical impact is genuinely high: a guest can both read and write arbitrary host directories, defeating the core security guarantee of the runtime. However, the exploitation surface is materially constrained and the raw score should be read against several tempering signals. Attack requirements are present (AT:P in the supplied vector) because only macOS and FreeBSD hosts are affected - Linux and Windows are explicitly NOT vulnerable because their renameat does not follow a trailing-slash symlink - so a large share of real deployments (which skew to Linux servers) carry no exposure. The attacker must also already be a guest granted write access to a sandbox directory (PR:L), meaning this matters specifically to embedders who run untrusted or semi-trusted WASM guests on macOS/FreeBSD. No EPSS score was provided and the vulnerability is not on the CISA KEV list, so there is no evidence of active exploitation; the vuln.today decision label is 'this_week' (not act_now/emergency), consistent with a serious-but-not-under-attack issue. No verified working exploit code was supplied - only the GHSA and VulnCheck advisories, which describe the mechanism precisely. One signal to flag explicitly: the supplied CVSS 4.0 vector uses AV:N, but the actual trigger is in-process execution of malicious guest code, which is better modeled as a local execution context (AV:L) whose network reachability depends entirely on how the embedding application delivers guests - verify against your deployment. Net: a real priority to patch for anyone running untrusted guests on macOS/FreeBSD, and effectively not applicable on Linux/Windows.

On a macOS or FreeBSD host running an affected wasmtime-wasi version, a malicious or compromised WASM guest that has been granted write access to a preopened directory creates a relative symlink pointing outside its sandbox (e.g. symlink("../outside", "up")) and then renames "up/" to a path inside its sandbox. The host kernel follows the trailing-slash symlink during the renameat syscall and moves the external host directory into the sandbox, after which the guest can read and write its contents. No public exploit code was identified at time of analysis, but the GHSA advisory describes the trigger in full.