Wasmtime: WASI hard links bypass wasmtime-wasi's FilePerms for destination

Why it is Yellow

• CVSS 6.5 medium

Affected packages

References

• https://github.com/advisories/GHSA-4ch3-9j33-3pmj
• https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-4ch3-9j33-3pmj
• https://nvd.nist.gov/vuln/detail/CVE-2026-58494
• https://github.com/bytecodealliance/wasmtime/pull/13725
• https://github.com/bytecodealliance/wasmtime/commit/5ddfd5f1ef28f2041fa07d237ad0336e167b0e0c
• https://github.com/bytecodealliance/wasmtime/commit/7db94cdcf0c79cb3dfde884b534b653f2dd83367
• https://github.com/bytecodealliance/wasmtime/commit/8a250aac0962ca1364b5f16525720e9d0b39edcd
• https://github.com/bytecodealliance/wasmtime/commit/d3ceb56ec35f39e02496eeb4e2d9c7f4fb964d9e
• https://github.com/bytecodealliance/wasmtime/releases/tag/v24.0.11
• https://github.com/bytecodealliance/wasmtime/releases/tag/v36.0.12

Original description

## Summary Wasmtime's WASI filesystem implementation lets a guest with a read-only source file capability overwrite that file by hard-linking it into another preopen that allows file writes. An attacker who can run a WASI guest can bypass `WasiCtxBuilder` per-preopen `FilePerms` and modify host files that were exposed as `FilePerms::READ`. This attack is possible through the wasip1, wasip2, and wasip3 interfaces to the WASI filesystem. This attack is also possible through an indirection of renaming a hardlink into another preopen. ### Details `WasiCtxBuilder::preopened_dir` documents `file_perms` as the maximum permissions usable for files in that preopen. However, hard-link creation and renaming only checked directory mutation for permission, and not whether the file permissions matched. This makes an attack possible where: * a read-only file `target` exists in a preopen with only FilePerms::READ * a hardlink named `alias`, with destination to the `target`, is created in a preopen with FilePerms::READ | FilePerms::WRITE * the attacker opens the file `alias` for writing, in which they can overwrite `target` The same attack is possible by way of renaming: * a read-only file `target` exists in a preopen with only FilePerms::READ * a hardlink named `alias`, with destination to the `target`, is created in that same preopen * the `alias` file is renamed into a preopen with FilePerms::READ | FilePerms::WRITE * the attacker opens the file `alias` for writing, in which they can overwrite `target` Symbolic links are not a vector for this attack because the wasi-filesystem interfaces already enforces that the destination for a symlink is under the same preopen. We do not believe there are any other vectors to this attack because there are no other wasi filesystem interfaces that take multiple borrows of a descriptor resource for e.g. the source and destination in different descriptors. ### Remediation The definition of `Dir::link_at` and `Dir::rename_at` in wasmtime-wasi's `src/filesystem.rs` now have an additional permissions check that ensures the source and destination values for the directory permissions `perms` and the file permissions `file_perms` are identical. ```rust if self.perms != new_dir.perms || self.file_perms != new_dir.file_perms { return Err(ErrorCode::NotPermitted); } ``` ### Impact Only wasmtime-wasi embeddings that use a combination of DirPerms::MUTATE with FilePerms::READ, as well as using a second preopen with higher permissions (FilePerms::WRITE as well), are affected by this bug, e.g. those that use in the WasiCtxBuilder: ```rust builder.preopened_dir("readwrite", "readwrite", DirPerms::READ | DirPerms::MUTATE, FilePerms::READ | FilePerms::WRITE); builder.preopened_dir("readonly", "readonly", DirPerms::READ | DirPerms::MUTATE, FilePerms::READ); ``` In particular, the Wasmtime project's wasmtime-cli's use of wasmtime-wasi is not affected, because it always sets FilePerms::all() for all preopens.