@173787247/dsh-wsl-obscura

DEFAULT_CANDIDATES is built from every directory under /mnt/c/Users, including the world-writable C:\Users\Public profile (and any other local account's Desktop if writable). resolveObscuraBin only calls existsSync() and then index.js executes the first match with execFile, so a lower-privileged local Windows user could plant obscura.exe at e.g. C:\Users\Public\Desktop\obscura\target\release\obscura.exe and get code executed in the DSH/plugin user's context. No hash, owner or signature check is performed.

isSafeHttpUrl only enforces that the scheme is http/https (line 38: `if (u.protocol !== "http:" && u.protocol !== "https:")`) — no host, IP, or loopback/link-local filtering happens in the plugin. Whether http://127.0.0.1:*, http://169.254.169.254/ or LAN hosts can be reached depends entirely on the external obscura binary's default, and the exposing tool accepts allowPrivateNetwork from the same (LLM-driven, potentially page-influenced) caller, whose description explicitly says "SSRF guard off". This gives a prompt-injection-driven path to probe host-internal services.

runPowerShell/runCmd accept a caller-supplied script and pass it to powershell.exe/cmd.exe -Command, i.e. a generic host command-execution primitive with no sanitising. In THIS plugin the functions are never imported or called (index.js only uses detectWsl), so the construct is currently unreachable; it is a latent risk for any future or sibling plugin that forwards untrusted text into runPowerShell.