EUVD-2026-42393Severity by source
AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:N
AV:L because exploitation requires controlling a WASI guest process on the same host; PR:L for that guest execution channel; S:C and I:H for host filesystem write bypass across the sandbox boundary.
Primary rating from Vendor (github).
CVSS VectorVendor: github
Lifecycle Timeline
2DescriptionCVE.org
Wasmtime is a runtime for WebAssembly. Prior to 24.0.11, 36.0.12, 45.0.3, and 46.0.1, wasmtime-wasi hard-link creation and renaming check directory permissions but not matching FilePerms on source and destination preopens, allowing a WASI guest with a read-only source file capability to overwrite host files exposed as FilePerms::READ through wasip1, wasip2, or wasip3 filesystem interfaces. This issue is fixed in versions 24.0.11, 36.0.12, 45.0.3, and 46.0.1.
AnalysisAI
Wasmtime's WASI filesystem implementation allows a sandboxed WebAssembly guest to overwrite host files that were intentionally exposed as read-only preopens. The wasmtime-wasi component checks directory-level permissions during hard-link creation (path_link) and rename (path_rename) operations but fails to verify that the source and destination preopens carry matching FilePerms flags - meaning FilePerms::READ enforcement is bypassed at the operation level. Affected versions span multiple major release trains (prior to 24.0.11, 36.0.12, 45.0.3, and 46.0.1); no public exploit code or CISA KEV listing is present at time of analysis, but the scope change from guest sandbox to host filesystem makes this a meaningful sandbox-escape class defect.
Technical ContextAI
Wasmtime is the Bytecode Alliance's production WebAssembly runtime, implementing WASI (WebAssembly System Interface) filesystem APIs across wasip1, wasip2, and wasip3 interface generations. The WASI filesystem model uses 'preopens' - capability handles that grant a guest bounded access to host directories - and associates each preopen with FilePerms flags (READ and/or WRITE) to constrain allowed operations. CWE-281 (Improper Preservation of Permissions) identifies the root cause: the wasmtime-wasi path_link and path_rename syscall implementations enforce directory-level ACL checks but omit a cross-check of the FilePerms bitmask on both the source and destination preopen handles. Because hard-link creation and rename are structural filesystem operations that can redirect a path to any inode the process can reach, a guest holding only a FilePerms::READ capability on a preopen can exploit this gap to overwrite arbitrary host files exposed under that preopen, violating the intended capability-based security boundary.
RemediationAI
Upgrade to one of the vendor-released patched versions: v24.0.11, v36.0.12, v45.0.3, or v46.0.1, available from the Bytecode Alliance GitHub releases page and the official security advisory at github.com/bytecodealliance/wasmtime/security/advisories/GHSA-4ch3-9j33-3pmj. The upstream fix is confirmed across four commits (5ddfd5f, 7db94cd, 8a250aa, d3ceb56). If immediate upgrade is not possible, operators can restrict the host filesystem paths exposed to WASI guests to the minimum necessary scope and avoid granting any preopens to host directories containing sensitive or mutable files, accepting the trade-off of reduced guest functionality. Additionally, running untrusted WASM modules with only write-capable preopens (rather than mixing read-only and write-capable preopens in the same guest) prevents the cross-preopen permission bypass from being triggered. Wasmtime's component sandboxing at the process level (e.g., running each guest in a separate OS process with restricted filesystem namespaces via Linux namespaces or seccomp-bpf) would provide a defense-in-depth layer, though with measurable operational overhead.
Same weakness CWE-281 – Improper Preservation of Permissions
View allSame technique Information Disclosure
View allVendor StatusVendor
SUSE
Severity: ModerateShare
External POC / Exploit Code
Leaving vuln.today