weshop-dsh-plugin

The handler never checks authentication, Origin, or Content-Type, and readJsonBody just JSON.parses the raw body. Any page the user visits while the DSH web server is running can issue a simple (no-preflight) POST with content-type text/plain to http://127.0.0.1:<port>/api/weshop/config or /state and overwrite the persisted WeShop API key (or delete it), or replace the whole canvas state that the agent later reads with weshop_canvas_get_state. Side effects occur even though CORS hides the response; DNS rebinding would also expose reads.

State/actions/requests/progress live in shared os.tmpdir() with default write permissions and are read with fs.readFileSync/appendFileSync/writeFileSync without O_EXCL or a private directory. On a multi-user host another local user can read canvas state (item metadata, prompts, local paths, provenance) and, by pre-creating the fixed path or a symlink, influence or redirect a subsequent write by the DSH user.

weshop_canvas_add_image/publish_result/publish_asset accept an arbitrary absolute localPath from model/tool input; the actions endpoint copies any existing file whose extension is in a whitelist (images, video, audio, .mp4/.txt, etc.) into WESHOP_ASSET_DIR and exposes it at the unauthenticated /api/weshop/assets/<id> URL. A prompt-injected agent turn can therefore turn local .txt/media files into remotely fetchable URLs. The extension whitelist and the lack of .html/.svg/.js mapping limit the impact (no key files without such extensions, no stored XSS).

installBundledPreset() runs on every apply() and, when the existing ~/.dsh/.agent-presets/weshop-canvas/agent.cordis.yml still contains the legacy mcp__weshop-canvas__ marker, silently replaces it (and preset.yml) with package-shipped content that was not part of the audited source; the shipped preset/skills/assets are also read and registered at runtime. A backup is written, so this is a migration/hardening gap rather than a demonstrated compromise.