dsh-wei-sitecontrol

normalizeTarget copies password/passphrase/privateKey verbatim into the target record, and JsonStore.write() serialises the whole registry to $DSH_HOME/storages/dsh-wei-sitecontrol/registry.json with mode 0666 & umask. Any local reader (another plugin, a backup or log dump, a support bundle) obtains reusable SSH credentials for every managed server. publicTarget does mask these fields for the UI, so the exposure is at rest, not through the API.

serviceName (also substituted into 'docker stop $(docker ps -q --filter "name=$SERVICE_NAME")' via base.replace(/$SERVICE_NAME/g, target.serviceName)) and lib/ssh.js serviceCommand ('return `systemctl ${action} ${name}`') build remote shell text without quoting. serviceName can come from the operator, or from parseProfileText() in lib/profile.js, whose regex [^\s,;,。]+ accepts characters such as $, (, ) and |. Deploying such a target therefore executes attacker-chosen commands on the remote host with the SSH user's rights (typically root, since user defaults to 'root').

Confirms the static scanner's flagged construct: any caller able to create or update a site record (the agent tool or the /dsh-wei-sitecontrol HTTP API implemented in index.js, which was not supplied) can run arbitrary shell commands as the DSH process user, with no quoting or allow-list. This is the plugin's documented purpose rather than a hidden backdoor, but it means the plugin's authorization boundary is entirely the unwritten site-write path, and a prompt-injected agent could turn a site registration into host code execution.

Every supervised site command (including third-party npm/pip start scripts and auto-restarted processes) receives DSH's entire environment, i.e. any harness/API tokens present there. The registry layer deliberately filters SECRET_FIELDS out of site.env (lib/registry.js envMap), but that defence is undone by spreading process.env directly into the child.

push() only rejects ssh:// and scp-style remotes; a remote configured as http:// (or a plain-HTTP URL reached after a redirect inside lib/githttp.js) receives the resolved token as Basic credentials in cleartext. The token may come from process.env[site.git.tokenEnv], i.e. a real repository credential.