WASI hard links let guests write files declared read-only across preopens

An agent tool may be allowed to read one directory and write another while the runtime labels these as separate authority scopes. In the affected Wasmtime WASI implementation, the guest could hard-link a file from a read-only preopen into a writable preopen. The second pathname still referred to the same underlying inode. Modifying the writable alias consequently changed data that the first directory had exposed as read-only.

A validator that checks permissions only against the destination pathname misses the relevant property: filesystem permissions must follow the object being mutated, including any aliases. The advisory covers particular WASI preopen permission combinations, not unrestricted host filesystem access. It did not demonstrate code execution outside the sandbox or reading files outside all exposed directories.

Wasmtime published fixes across multiple maintained versions. The effective risk depends on the embedding application's preopens, directory permissions and capability assignment. A regression test should create a harmless file under a read-only preopen, attempt a hard link into a writable preopen, and verify that both linkage and mutation fail consistently without blocking legitimate permitted filesystem operations.