dsh-plugin-ollama-monitor

runPkTask takes the raw answer of an Ollama model and evaluates every candidate extracted by extractPkCandidates (which includes the whole response text) inside the plugin's own Node process, with no vm/worker isolation. `process` is a global inside a Function body, so hostile output can spawn processes (child_process via process.getBuiltinModule/mainModule), read the filesystem and env, and exfiltrate over the network with the same privileges as DSH. Precondition: the user starts ollama_codepk against a model that returns malicious code (a model pulled from HF/ModelScope, or a prompt-injected

The settings panel's PK runner evaluates model answers in the DSH client page. Code produced by a malicious or prompt-injected model runs with the page's privileges: it can read/write localStorage (including any DSH session state stored there), rewrite the UI, and issue authenticated same-origin requests to the plugin's /ollama-monitor routes (pull models, start imports) or exfiltrate data to any host.

The plugin registers prefix routes on ctx.webServer and mutates state on POST (catalog scan that fetches ollama.com, GGUF download/cancel, model creation in Ollama) without checking Origin/Referer or a CSRF token. If the DSH web server authenticates by cookie, a cross-site top-level form POST can trigger these actions (bounded impact: outbound fetches, tmp file writes, Ollama model creation).