@7gzgn/dsh-restart-dock

The custom-header requirement only defeats browsers (a cross-site fetch triggers a preflight the plugin never answers). Any non-browser client — a local process, a script, or a remote host that can reach the listener when DSH binds 0.0.0.0/:: (a binding configuration the code's own comments anticipate) — can send 'x-dsh-restart-dock: 1' with no Origin and POST /dsh-restart-dock/restart, killing and relaunching the host without user interaction: denial of service and loss of in-flight work. The status route additionally discloses host pid, platform and the absolute state directory to the same c

info.stateDir derives from process.env.DSH_HOME or the user's home directory. cmd.exe re-parses the composed command line, and Node's Windows argument quoting does not fully protect cmd metacharacters (&, ^, "), so a home/DSH_HOME path containing such characters could break argument boundaries. Exploitation requires control over the local environment or profile path, and no attacker-supplied string reaches the command, so practical impact is limited to a hardening gap.

The code that actually stops and relaunches the host runs as a detached process with execution policy disabled, outside the audited process boundary. Its content is not present in the harvested files, so it could not be verified — including whether it probes the target process as the header comment claims, or terminates anything whose pid it is given. If the file is genuinely missing from the package, the restart feature is simply inert.