@Winnie-0721/dsh-plugin-market

spawnRestartHelper() calls buildHelperCommand with `env: process.env`; buildRestartPayload copies every string entry into payload.env, which is JSON+base64 encoded into a single argv element passed as `node restart-helper.cjs <payload>`. On Linux /proc/<pid>/cmdline is world-readable, and the payload is also visible in `ps`/Windows process listings, so any local user (or any process that can read the command line) can decode API keys, tokens and proxy credentials while the helper lives (up to RESTART_HELPER_WAIT_MS = 60s).

In the client-only branch the row is `{ id: `client-${packageName.replace(/[^A-Za-z0-9_.-]/g, '-')}`, name: packageName }` — the id is sanitised but the name is used raw, and resolveProfileEntry() passes names starting with '.', '/', 'file://' or 'cordis:' through unchanged. A package name containing a single quote (or a file:///absolute path that also has a real directory under node_modules declaring dsh.client) breaks out of the quoted scalar and lets the marketplace write arbitrary rows into a YAML file that the cordis Include loader then executes, i.e. attacker-chosen module loading in the

0.0.0.0 is a bind address, not a loopback name; accepting it in the Host allow-list widens the DNS-rebinding wall for the restart endpoint beyond the intended localhost/127.0.0.1/::1 set. Exploitation still requires a loopback peer address (directLoopbackRequest) and a matching Origin, so no concrete bypass is demonstrated — this is a hardening gap.

All route handlers, the auth/session check and the mapping of request fields into restart/hot-mount options live in lib/index.js, which is absent from the provided files. Whether spawnRestartHelper receives attacker-controlled execPath/args/env, and whether install names are validated before hotMount, could not be verified; the residual risk of the restart and hot-mount paths is therefore higher than the audited code alone suggests.