@173787247/dsh-remote-ssh

assertAllowedCommand (lib/ssh.js:38) only validates the command name, never its arguments, and remote_ssh_run feeds the returned stdout straight back to the model (index.js render: v.stdout). With the shipped default allowlist, a prompt-injected or simply curious agent can call remote_ssh_run with argv ["cat","/home/<user>/.ssh/id_rsa"] (or /etc/shadow, application secret files, cloud credentials readable by the SSH user) on any configured host and receive the file contents in the transcript, exfiltrating remote secrets to the model provider without any confirmation step, because read-only com

Every ssh invocation accepts an unknown host key silently, so the first connection to a host (or any later connection where DNS/ARP/routing is manipulated) can be intercepted by an on-path attacker; the attacker can then observe and alter the allowlisted commands and their output that this plugin returns to the model. No user-known-hosts file is provided, so the risk is permanent for hosts whose key is never verified out of band.

The example entrypoint copies an SSH public key from /tmp into the dshprobe account's authorized_keys and then runs sshd, so any process able to write /tmp before container start can install its own key and obtain a shell as dshprobe inside the lab image. Impact is limited to this example/test container: the harness never loads entrypoint.sh (it is not referenced by package.json main or dsh.bundle.patch), so there is no runtime reachability in the plugin itself.