dsh-danger-guard

The route family performs no authentication or origin check of its own and accepts any string in ruleId, persisting it into the security-relevant alwaysAllow setting. A single POST {"ruleId":".*","always":true} makes every subsequent command pass the gate, including critical rules such as rm -rf / (the alwaysAllow check runs before decideGuard and returns next()). Because the guarded agent can itself run curl against the local host web server, this is a self-bypass path for the exact threat the plugin exists to stop. The same route family also returns the last 20 intercepted command strings vi

A value the user believes to be a rule id is instead a regex over the raw command text. Narrow-looking values therefore either do nothing (id never appears in a command) or over-allow: a broad pattern disables the gate for arbitrary commands, including critical rules, without the user meaning to create a whitelist.

The host HTTP handler buffers an entire request body in memory with no cap; a large POST to /dsh-danger-guard/api/exempt can exhaust memory of the host process. Low severity because it needs network/loopback access to the host web server.

The script executes lib/client.js as code via eval. It is developer tooling invoked manually via node (not referenced by the plugin's dsh entry, main/exports or cordis.patch.yml), so it is not reachable at runtime; the residual risk is that anyone able to write lib/client.js before the script is run gets code execution in the developer's shell.