dsh-desktop-packager

logoPath comes straight from the user-editable config and is settable through the unauthenticated route (`case 'setDesign': this.setDesign((payload && payload.design) || {})`). No allow-list, no directory confinement and no permission check: an attacker who can reach the web server sets logoPath to any readable file (e.g. ~/.ssh/id_rsa, ~/.dsh credentials) and then GETs /api/desktop-config/logo to receive its bytes base64-encoded. The extension check only picks a mime label, so it does not constrain the read.

The route switch accepts state-changing actions from any client that can reach the DSH web server, with no authentication and no use of the plugin's PERMISSION_KEYS model (only the catch-all 500 guard is applied). An attacker can create an account with arbitrary permissions or delete accounts in the packaged app's login gate, rewrite the bundled plugin/model selection, and POST /api/desktop-config/package with an arbitrary dshCheckoutDir/out to start a build.

appName comes from desktop.json (itself writable through the unauthenticated route above) and is interpolated raw into the data: URL login page, which has no CSP and holds the desktopAuth preload bridge. A value such as `</h1><script>…</script>` executes script in the window that collects the desktop-app username/password, allowing credential exfiltration or login bypass.

themeColor/backgroundColor are arbitrary strings accepted by the config route; a value containing `}` closes the :root block and lets the attacker append arbitrary CSS rules to the DSH page rendered inside the packaged app (UI spoofing, forced remote resource loads / tracking). Impact is limited to the shell window.

When no password is supplied (the UI explicitly allows it: `password: password || undefined` and the hint "新增时留空则密码为空"), the account is stored as a scrypt hash of the empty string, so the packaged app's login gate accepts an empty password for that user.