DSH-Plugin-Market

The only access control on /install, /update, /uninstall, /setup-pnpm and /toggle is that the Origin header's host equals the Host header. Any non-browser client can forge both headers, and a DNS-rebinding page (origin host == rebound host) satisfies the check in a browser too, giving a remote page the ability to trigger `dsh plugin add github:<repo>` — i.e. install and execute third-party code with the user's privileges.

Any GitHub repo's README is fetched and handed to the browser verbatim except for URL rewriting: HTML tags (e.g. `<img onerror=...>`) are deliberately preserved. The market UI is served from the same origin as the privileged POST routes, so if the client renders HTML/markdown without escaping (client/client.js was not harvested, so this could not be verified), a malicious README yields same-origin script execution that can call /install (with force=true) and reach code execution.

Only arguments containing whitespace are quoted; `&`, `|`, `>` and `%` are never escaped, so an argument such as `<name>@latest` or `remove <name>` (name taken from the profile manifest keys) containing a cmd metacharacter is interpreted by cmd.exe as a second command. On POSIX spawn() is used without a shell, so this is Windows-only and requires a dependency key with such characters.

With the gate disabled the install route refuses outright, but /update still runs `dsh plugin add <name>@latest` (or re-resolves the git HEAD), so a newer, unaudited release can be pulled and executed without any scan or lifecycle-hook check.

`name` comes from the JSON body and is only required to equal an existing loader-row name; a loader row whose name contains `../` (attacker-influenced via an installed plugin's cordis.patch.yml insert row) turns the cleanup into a recursive delete / read outside the profile directory. The precondition is an already-installed plugin, which already executes code in the host, so the marginal gain is small.