Listen to this Post
Wasmtime’s WASI filesystem implementation contains a security flaw in how preopened directory permissions and file permissions are validated during hard-link creation and renaming operations across different preopens. The vulnerability stems from the fact that `WasiCtxBuilder::preopened_dir` defines granular permissions (FilePerms) to control whether a guest WebAssembly module can read or write specific files. However, operations like `link_at` and `rename_at` previously only checked whether the directory permissions permitted mutation, failing to verify whether the source file and destination directory file permissions matched. This flaw allows a malicious guest with read-only access to a source file capability to create a hard link or rename that file into another preopen context that possesses write permissions. Once the file is linked or moved into the write-enabled preopen location, the attacker can open the alias file for writing and overwrite the contents of the original read-only host file. This breaks the isolation guarantees intended by `WasiCtxBuilder` per-preopen file restrictions across wasip1, wasip2, and wasip3 interfaces.
DailyCVE Form:
Platform: Wasmtime WASI
Version: Prior to 24.0.9
Vulnerability : FilePerms Bypass
Severity: Medium
date: 2026-07-08
Prediction: 2026-07-08
What Undercode Say:
Analytics
The vulnerability allows WebAssembly guests to bypass intended file permission boundaries by exploiting insufficient checks in `Dir::link_at` and `Dir::rename_at` within wasmtime-wasi. Since directory-level mutations were validated without cross-checking the exact source and destination file permissions (file_perms), mismatched preopen configurations permitted unauthorized write escalation to read-only host files.
How Exploit: (Educational Purposes!)
- Expose a host file target within a preopen configured with
FilePerms::READ. - Expose a second preopen configured with
FilePerms::READ | FilePerms::WRITE. - Execute a WASI hard-link or rename operation from the read-only preopen context pointing to the write-enabled destination directory path.
- Open the newly created hard-linked alias file using write permissions to modify the underlying host file target.
Protection: from this CVE
Upgrade `wasmtime-wasi` to version 24.0.9 or later, where an explicit permission equality check (self.file_perms != new_dir.file_perms) is enforced during directory link and rename operations. Ensure custom embedders validate file permission boundaries when utilizing multiple preopened directories with mixed permission levels.
Impact
Applications embedding `wasmtime-wasi` that configure multiple preopened directories with mixed permission levels—specifically combining `DirPerms::MUTATE` with restricted `FilePerms::READ` alongside secondary preopens allowing FilePerms::WRITE—are vulnerable to unauthorized host file modification by untrusted WebAssembly guests.
🎯Let’s Practice Exploiting & Learn Patching For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
