Summary In "wasmtime-wasi", when a filesystem preopen is given "DirPerms::all()" and "FilePerms::READ" without "FilePerms::WRITE", this wasmtime-wasi enforced access control mechanism can be bypassed by using the wasip2 "descriptor.open-at" or wasip1 "path_open" interfaces by opening a file with "OpenFlags::TRUNCATE" oflag only, for example: dir_descriptor.open_at( PathFlags::empty(), FILENAME, OpenFlags::TRUNCATE, DescriptorFlags::READ, ) wasip1::path_open( dir_fd, 0, FILENAME, wasip1::OFLAGS_TRUNC, wasip1::RIGHTS_FD_READ, 0, 0 ) The root cause is that the clause that considered "OpenFlags::TRUNCATE" did not set "open_mode |= OpenMode::WRITE;", used later in that function for the access control check against "FilePerms" for whether opening that file is permitted. With the bug corrected, these calls to "open-at" and "path_open" fail with "error-code.not-permitted" and "ERRNO_PERM" respectively. The bug in "crates/wasi/src/filesystem.rs", "Dir::open_at", lines 967–969: if oflags.contains(OpenFlags::TRUNCATE) { opts.truncate(true).write(true); } and the single line fix is: if oflags.contains(OpenFlags::TRUNCATE) { opts.truncate(true).write(true); open_mode |= OpenMode::WRITE; } Only wasmtime-wasi embeddings that use a combination of DirPerms::MUTATE with FilePerms::READ are affected by this bug, e.g. those that use in the "WasiCtxBuilder": 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.