CVE-2026-58494

## 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