Improper Preservation of Permissions Affecting wasmtime-wasi package, versions <24.0.11>=25.0.0 <36.0.12>=37.0.0 <45.0.3>=46.0.0 <46.0.1
Threat Intelligence
The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
Do your applications use this vulnerable package?
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applications- Snyk IDSNYK-RUST-WASMTIMEWASI-17905492
- published9 Jul 2026
- disclosed8 Jul 2026
- creditsdjasj
Introduced: 8 Jul 2026
NewCVE-2026-58494 (opens in a new tab)How to fix?
Upgrade wasmtime-wasi to version 24.0.11, 36.0.12, 45.0.3, 46.0.1 or higher.
Overview
wasmtime-wasi is a Crate defining the Wasi type for Wasmtime, which represents a WASI instance which may be added to a linker.
Affected versions of this package are vulnerable to Improper Preservation of Permissions via the Dir::link_at and Dir::rename_at filesystem paths in src/filesystem.rs. An attacker can overwrite a host file exposed as read-only by creating a hard link to it in a writable preopen, or by renaming that hard link into a writable preopen and then opening it for writing. The affected WASI guest can cross from a preopen with FilePerms::READ into one with FilePerms::WRITE because hard-link creation and rename operations only enforced directory mutation checks and did not compare the source and destination file permission domains. This lets a malicious guest modify files that were intended to be read-only, breaking host file integrity for embeddings that expose mixed-permission preopens.
Notes
- The affected behavior is gated by embeddings that combine a mutable preopen with a separate preopen exposing the same host file under different
FilePerms;WasiCtxBuilder::preopened_dirtreats those permissions as the maximum usable for that preopen, so mixed read-only/read-write setups are the vulnerable deployment pattern. - The issue spans the WASI filesystem interfaces used by wasip1, wasip2, and wasip3 guests, but not embeddings such as
wasmtime-clithat exposeFilePerms::all()for every preopen.
Workarounds
- Use
WasiCtxBuilder::preopened_dironly with matchingDirPermsandFilePermsacross any preopens that a guest can move files between; do not mix a read-only preopen (FilePerms::READ) with a writable preopen (FilePerms::READ | FilePerms::WRITE) when the guest is allowed tolink_atorrename_at, because that blocks the hard-link/rename path used to overwrite a read-only host file.