dsh-download-pro

The scheme allow-list blocks file:// but places no restriction on destination hosts, so the aria2c process on the user's machine will issue requests to 127.0.0.1, 10/8, 192.168/16, link-local metadata endpoints, etc. Because the caller is an LLM that may be steered by untrusted content, this is an SSRF primitive for probing/internal services and for writing the internal response bodies to disk.

The tool description only says 'override default download dir', but no containment check ties `dir` to config.dir, so a task can be written to any directory the user can write (e.g. autostart/config/cron locations), and `out` sets the file name. aria2's --allow-overwrite=false/--auto-file-renaming limits overwrite, but new-file creation anywhere is fully attacker/LLM-controlled and is a persistence vector.

The token file is created without an explicit mode (typically 0644 under umask 022) and the same secret is passed as `--rpc-secret=${this.secret}` (src/aria2.ts:121), visible in `ps`. Any other local user on a multi-user host can read the secret and drive the loopback-bound aria2 RPC (add downloads, write files) with the host user's privileges.

Deletion targets come from aria2.tellStatus file paths (influenced by the torrent/HTTP task, and by the caller-supplied `dir` above) and the parent directory of the first path is also `rmSync(..., {recursive:true})` when it is empty. No check ties these paths to config.dir, so a task created outside the download root can cause recursive deletion of files/dirs in unrelated locations.