Activepieces 代码执行链中的三个漏洞分析

沙箱不是功能，是产品本身

当一款产品的核心卖点是“你随便写代码，我保证安全运行”时，沙箱就不再是附加功能，而是产品本身。其余的一切 UI 和流程编排，都只是围绕这个承诺的外壳。

对于这类平台，真正值得问的问题从来不是“沙箱够不够好”——V8 isolate、nsjail 这些技术本身通常都没问题。真正关键的问题是：沙箱从哪一行代码开始生效？

沙箱不是系统的一个属性，而是源码中的一条分界线。分界线之上，受攻击者影响的代码以宿主进程的权限运行；分界线之下，隔离边界才真正生效。安全审计人员往往聚焦分界线之下的“有趣代码”，但真正的漏洞往往藏在分界线之上。

目标：Activepieces 的四种执行模式

Activepieces 是一个开源工作流自动化平台，GitHub 约 23,400 星，常被自托管用户用于 SaaS 集成。用户通过画布构建流程，其中一种步骤类型是 Code step，允许编写 JavaScript 作为流程的一部分运行——这正是沙箱存在的全部理由。

平台提供四种执行模式：

• UNSANDBOXED：无任何隔离
• SANDBOX_PROCESS：仅进程隔离
• SANDBOX_CODE_ONLY：仅 V8 isolate，无 Node.js API
• SANDBOX_CODE_AND_PROCESS：V8 isolate + 进程隔离

其中 SANDBOX_CODE_ONLY 是最值得攻击的模式，因为这是唯一一种 V8 isolate 承担全部安全责任的场景。其他模式下，要么没有 isolate，要么有进程沙箱在底层兜底。如果 isolate 会出问题，一定是在这个模式下暴露。

漏洞生命周期：边界在哪里？

有效的攻击思路不是直接对抗 isolate，而是追踪 Code step 从提交到执行的完整生命周期，标记边界开始的确切语句。大致流程如下：

1. HTTP 请求创建或编辑流程
2. 请求级 schema 校验
3. 步骤记录持久化
4. Worker 拾取流程
5. Worker 将步骤写入执行环境

问题在于：前四步都发生在沙箱启动之前。攻击者可以在这些阶段注入恶意数据，而这些数据会以宿主进程权限被处理。

三个漏洞：同一条时间线的不同切面

2026 年 3 月，Activepieces 发布了三个安全公告，分别在 0.80.0 和 0.83.0 版本中修复，CVE 编号在 8 月分配。其中两个高危漏洞本质上是同一个架构问题在时间线不同位置的表现，第三个则是不同攻击面但底层失败模式相同。

CVE	GHSA	严重性	报告者
CVE-2026-73081	GHSA-3pfv-m69p-5fv5	高	p80n-sec, kodareef5, Aviral Srivastava
CVE-2026-73083	GHSA-gr3h-c2j7-r52g	高	p80n-sec, Aviral Srivastava, q1uf3ng
CVE-2026-73084	GHSA-hc39-cm5m-q8g7	中	Aviral Srivastava, diemoeve

作者于 3 月 11 日提交了 XSS 公告，并在两个高危漏洞中作为共同报告者（由 p80n-sec 于 3 月 30 日提交）。三周内三位研究者独立发现同类问题，说明该攻击面长期缺乏审计。

两个高危漏洞都发生在 isolate 启动之前——攻击者可以在流程定义或执行准备阶段注入代码，这些代码在沙箱边界建立前就以宿主权限执行。反射型 XSS 则将攻击者数据放入脚本块中，在浏览器端触发，与沙箱无关。

对开发者的实用启示

1. 审计沙箱边界之上：不要只审查隔离机制本身，要追踪所有在沙箱启动前处理攻击者输入的数据流。
2. 明确隔离起点：在代码中显式标记沙箱边界开始的位置，并确保所有攻击者可控操作都在边界之后。
3. 模式选择要谨慎：如果必须支持“仅 V8 isolate”模式，要意识到它无法防御进程级的攻击，需要额外的防护层。
4. XSS 仍是独立威胁：即使沙箱完美，反射型 XSS 依然可以绕过所有服务端防护，前端输出编码不可省略。

对于使用 Activepieces 的团队，建议尽快升级到 0.83.0 以上版本，并审查现有流程中是否有在沙箱启动前处理用户输入的 Code step。