@guanhaisen/dsh-agent-browser

The tool description the model sees promises 'Only HTTP and HTTPS addresses are accepted, and the DSH application itself cannot be opened', yet neither index.js (browser_navigate execute just forwards {url: args.url}) nor client.js checks the scheme or host before calling guest.loadURL(url) on an existing tab. Any scheme the guest accepts (file:, data:, the app's own origin/localhost endpoint) can therefore be loaded into a drivable tab and then read back with browser_read/browser_screenshot, giving the model a local-file/internal-endpoint read primitive that the advertised contract says is im

pageEval (`new Function('"use strict";return (' + code + ')')()`) is evaluated inside the guest, so enabling it means arbitrary script per model request; if the sidebar's webview had Node integration enabled this would extend beyond page scope. The static scan's single 'critical' is this construct. It is refuted as a default posture: DEFAULTS.enableEval is false, the browser_eval tool is not registered, and the tools.guard above blocks the inspect-query bypass the plugin itself identified. Residual gap: the guard matches one tool name and one provider/method string, so any other entry point to

Field values are collected for every matched input with no type filtering, so a password (or other sensitive) field the user typed into the sidebar browser is serialized into the tool result and sent to the model, even though the tool description only promises 'interactive elements you can act on'. This is a silent credential-capture channel into model context.