跳到正文
原文
arXiv· arXiv:2609.33413· Eilon Cohen·本站收录· 原文发表精选关注度43

Weird Machine 组合器：在表达式层利用 AI 编排

Weird Machine Compositors: Exploiting AI Orchestration at the Expression Layer

论文速读

攻击

据论文 PDF 整理（Gemini 生成），以原文为准

作者分析n8n表达式沙箱，报告其AST覆盖率仅35%，通过三轮绕过达成CVSS 9.4与9.5的RCE，实现凭据截获。

威胁模型包含两类攻击者：1. 认证攻击者（Authenticated attacker）：具有工作流编辑权限，无需管理员权限；2. 未认证攻击者（Unauthenticated attacker）：任何网络可达主体，仅需公开表单URL（如/form/*）。

问题
AI编排平台普遍通过AST重写与运行时黑名单沙箱化用户表达式。然而编排系统常将表达式引擎、凭据库和运行时部署在单进程中，一旦沙箱被逃逸，存储的所有API凭据与外部系统访问权将被获取。
方法
作者将表达式沙箱形式化为怪异机，指出枚举黑名单无法跟上语言规范演进；分析多阶段求值导致的信任清洗机制；提出基于最小允许列表的策略反转与运行时隔离防御方案，并构建了AST规范覆盖率量化分析方法与工具。
实验与结果
对@n8n/tournament的AST覆盖率分析为35%（处理25/72个ESTree节点）。作者利用LLM辅助枚举等手段实现三轮绕过，获得三项CVE（CVSS评分分别为9.4、9.4和9.5），并完成了从未认证表单到凭据截获的端到端攻击链。
局限与可以继续做的
作者指出的局限包括策略反转无法消除运行时隔离需求、双重求值修复未推广至其他组件、组合怪异机未验证包含LLM的随机组件；实验覆盖范围集中于n8n且未报告辅助生成绕过表达式所使用的具体LLM名称与测试耗时。
实验设置@n8n/tournament、ESTree specification 等 · Coverage ratio、CVSS v4.0
威胁模型
包含两类攻击者：1. 认证攻击者（Authenticated attacker）：具有工作流编辑权限，无需管理员权限；2. 未认证攻击者（Unauthenticated attacker）：任何网络可达主体，仅需公开表单URL（如/form/*）。受害系统为表达式引擎、凭据库与运行时共存于单进程的编排平台。
基准
@n8n/tournamentESTree specificationn8n (nodes-base)
指标
Coverage ratioCVSS v4.0
AI 导读和推荐理由arXiv 论文以 n8n 的表达式沙箱为案例，论证基于 AST 枚举与黑名单的表达式沙箱无法充当安全边界。作者通过三轮升级绕过攻破 n8n 表达式沙箱，对应三个 CVE，其中两个 CVSS 9.4、一个 9.5 且无需认证；分析显示该沙箱只覆盖 ESTree 规范 72 种 AST 节点中的 25 种，覆盖率 35%，未处理的 47 种构成攻击者可用的指令集。论文提出组合式 weird machine 与信任洗白概念，并给出从公开表单到持久拦截 LLM API 调用的攻击链，建议以最小允许列表的策略反转加进程级隔离缓解，并配套开源 AST 覆盖率分析工具。所有漏洞均经协调披露报告给 n8n，n8n 在 24–48 小时内响应并发布补丁。

arXiv 论文以 n8n 的表达式沙箱为案例，论证基于 AST 枚举与黑名单的表达式沙箱无法充当安全边界。作者通过三轮升级绕过攻破 n8n 表达式沙箱，对应三个 CVE，其中两个 CVSS 9.4、一个 9.5 且无需认证；分析显示该沙箱只覆盖 ESTree 规范 72 种 AST 节点中的 25 种，覆盖率 35%，未处理的 47 种构成攻击者可用的指令集。论文提出组合式 weird machine 与信任洗白概念，并给出从公开表单到持久拦截 LLM API 调用的攻击链，建议以最小允许列表的策略反转加进程级隔离缓解，并配套开源 AST 覆盖率分析工具。所有漏洞均经协调披露报告给 n8n，n8n 在 24–48 小时内响应并发布补丁。

推荐理由论文以 n8n 三轮沙箱逃逸和三个 CVE 为例，说明 AST 枚举式表达式沙箱难以充当安全边界，并提供可复用的覆盖率分析方法。

深度解读

6个问题，点开问题读完整回答

  1. 这篇论文试图解决什么问题？

    作者称编排平台的枚举拦截式表达式沙箱存在结构性缺陷，导致攻击者可逃逸沙箱并完全窃取同进程凭据库。

    这篇论文试图解决AI编排平台中表达式沙箱无法提供有效安全边界，导致凭据泄露与系统被接管的问题。

    • 场景与重要性：在现代工作流自动化与智能体AI编排平台中，系统广泛使用表达式引擎求值用户提供的表达式；同时凭据库、表达式引擎与执行运行时共存于单进程或同一信任域，沙箱逃逸等同于凭据库被完全获取。
    • 现有方法的不足：现有编排平台普遍采用基于AST重写、运行时属性黑名单与模板沙箱的“枚举并拦截（enumerate-and-block）”方案；作者指出这种方案在结构上无法修复，因为语言规范不断扩充导致黑名单永远无法完备，且无法防御编译阶段的逃逸。
    • 核心观察与假设：作者提出表达式沙箱本质上是怪异机（weird machines），其指令集是底层语言规范，防御者的黑名单只是该规范的不完全枚举；当流水线中的求值阶段相互组合时，会通过信任清洗（trust laundering）抹去污点，产生单阶段不存在的突现计算。
    • 论文提出的方案：论文通过对n8n的三轮绕过提供了实证，提出了怪异机框架的三项扩展，开发了AST覆盖率量化分析方法与自动化工具，并提出以最小允许列表（策略反转）与进程级运行时隔离为核心的防御手册。
    • 威胁模型：
      • 攻击者目标：实现远程代码执行（RCE），读取进程环境变量中的加密密钥，解密并篡改凭据库，持久化拦截所有发往AI服务商等外部系统的API调用。
      • 攻击者知识与能力：分为两类：认证攻击者（Authenticated attacker）无需管理员权限，仅具有普通工作流编辑权限，其操作与正常编写工作流无异；未认证攻击者（Unauthenticated attacker）无需账户与认证，仅需网络可达的公开表单端点（如/form/*）。
      • 受害系统：表达式引擎、凭据库与工作流执行运行时共存于单进程或单一信任域的编排平台（如n8n）。

  2. 有哪些相关研究？

    作者将相关研究归纳为底层怪异机理论、动态语言与模板沙箱逃逸史，以及CI/CD与编排系统的表达式注入三类工作。

    作者在相关研究中重点讨论了三组工作，并对基线与本文定位进行了说明：

    • 怪异机理论基础（Weird Machines Theory）：Bratus 等（2011, 2014）与 Shapiro 等（2013）形式化了怪异机概念，将其定义为程序员预期计算与实际计算之间的差距，用于解释缓冲区溢出、格式化字符串与ROP链等底层漏洞。作者指出经典怪异机具有固定的指令集并在单一计算底座上运行，而编排层怪异机具有动态演进的指令集并跨处理边界组合。
    • 语言级沙箱与模板沙箱逃逸历史（Language & Template Sandboxing）：OpenJDK JEP 411（2021）记录了Java SecurityManager因长期处于“逃逸-修补-逃逸”循环而在Java 17中被弃用；vm2在经历反复逃逸后于2023年被弃用，并在2026年再次被绕过（CVE-2026-22709）。Jinja2的SandboxedEnvironment在CVE-2024-56326修复后被CVE-2025-27516通过|attr过滤器再次绕过；用于LangChain.js的安全表达式求值库expr-eval被披露CVE-2025-12735漏洞。作者以此论证枚举拦截式沙箱具有不可修复的生命周期轨迹。
    • 编排平台与流水线注入研究（Orchestration & CI/CD Injections）：Poutievski（2021）与 Ilgayev（2023）分析了GitHub Actions中的${{ }}注入漏洞，作者指出CI/CD流水线的${{ }}注入与编排平台的表达式注入属于同一漏洞类别。针对n8n，独立研究者报告了CVE-2025-68613，JFrog（Nehorai, 2026）报告了CVE-2026-1470（利用with语句）与CVE-2026-0863（利用Python属性内省）；Retool（2025）披露了沙箱与凭据加密密钥共享进程的架构漏洞；Bargury（2022）在Zapier中发现了利用账户共享Lambda模型的ZAPESCAPE漏洞。
    • 基线方法与基准：论文以n8n官方表达式引擎@n8n/tournament（v2.4.0前后的AST重写与运行时清理器）为分析对象，对照ESTree规范（ECMA-262第15版）定义的72种AST节点类型进行基准覆盖率度量。

    作者将本文定位为：将怪异机理论从底层二进制扩展至编排系统，提出了动态指令集、组合怪异机与信任清洗三项扩展，并提供了量化AST覆盖差距的分析方法与结构性策略反转方案。

  3. 论文如何解决这个问题？

    作者将沙箱形式化为怪异机，阐明编译期逃逸与多阶段信任清洗，提出AST覆盖分析与基于允许列表的策略反转。

    作者提出了编排层怪异机分析与防御框架，通过将AST未覆盖节点定义为怪异机指令集来量化沙箱攻击面，利用LLM辅助枚举生成利用载荷，并提出基于策略反转与运行时隔离的结构性防御体系。

    怪异机框架的编排层扩展与形式化

    作者识别出编排平台表达式引擎具备区别于经典怪异机的三个特性：

    • 动态指令集（Dynamic instruction sets）：经典怪异机的指令集由硬件架构固定，而表达式引擎的指令集是底层动态语言规范；随着ECMAScript（TC39）不断引入新语法与AST节点类型，防御者的枚举黑名单永远落后于规范。
    • 组合怪异机（Compositional weird machines）：两个各自正确的单阶段求值逻辑在串联后可组合出单阶段均不具备的恶意计算能力。
    • 信任清洗（Trust laundering）：输入在跨越不同处理节点时，系统默认下一阶段输入继承上一阶段的信任级别，从而逐级剥离污点。

    为此，作者定义了AST规范覆盖率计算公式： Coverage Ratio = (|𝒩handled|)/(|𝒩spec|) 其中分子为沙箱显式处理的AST节点集合大小，分母为语言规范定义的节点类型总数。对于双阶段求值，作者将组合指令集形式化为： ℐcomp = 𝒪Pass 1 ∩ ℰPass 2 即第一阶段作为字面量嵌入输出且能被第二阶段解析为可执行表达式的输入集合。

    表达式沙箱绕过机制与编译期逃逸

    针对n8n的@n8n/tournament沙箱架构，编译流程为：解析表达式为AST → VariablePolyfill重写危险标识符 → 编译为动态JavaScript函数 → 运行时清理器包装执行。作者通过两组绕过揭示了核心机制：

    • AST重写与原型操纵（Round 1）：利用TaggedTemplateExpression作为属性访问器、ArrowFunctionExpression作为this载体，配合Error.prepareStackTrace获取CallSite对象并执行代码；后续又利用Object.defineProperty通过CallExpression操纵原型链。
    • 编译期逃逸（Round 2）：构造{...process}将process标识符置于SpreadElement节点下。由于VariablePolyfill的switch语句仅覆盖25类节点，未包含SpreadElement，执行流落入default分支执行assertNever(parent)并返回true，导致重写被完全跳过；原生process标识符直接解析为Node.js全局对象，进而调用getBuiltinModule获取child_process实现RCE。该利用在编译期完成，使得所有9项运行时清理检查完全失效。

    多阶段求值组合与端到端攻击链

    在Form节点中，作者揭示了无需认证的双重求值漏洞（Round 3）：

    • 第一阶段（Pass 1）：Form.node.ts中的getNodeParameter解析配置表达式，将用户输入的表单数据作为字面量字符串嵌入HTML内容。
    • 第二阶段（Pass 2）：utils.ts中的prepareFormFields通过getResolvables()重新扫描已解析的HTML中的{{ }}表达式模式，并调用evaluateExpression()执行代码。

    基于上述漏洞，作者设计了6步端到端攻击链：

    1. 通过表达式注入达成RCE（CVE-2026-27577或CVE-2026-27493）；
    2. 读取环境变量N8N_ENCRYPTION_KEY；
    3. 利用OpenSSL兼容格式（AES-256-CBC配MD5 EVP_BytesToKey）解密credentials_entity数据库表；
    4. 篡改数据库中AI服务商凭据的baseUrl，指向攻击者控制的透明反向代理；
    5. 反向代理终止TLS并转发请求至真实服务商，截获Authorization头中的API密钥与全部载荷；
    6. 篡改持久化存储于数据库，重启后依然生效且前端界面无异常。

    AST覆盖率分析方法与防御策略

    作者提出了量化怪异机攻击面的五步方法：提取AST重写逻辑 → 枚举沙箱处理的节点类型 → 比对ESTree规范节点类型 → 按利用潜力分类（Critical、High、Medium、Low） → 计算覆盖率得分。在防御层面，作者提出了策略反转（Policy Inversion），将黑名单重写颠覆为仅放行工作流所需最小AST节点集合的允许列表，并强调必须结合V8隔离区、独立容器等进程级运行时隔离以及凭据分离架构。

  4. 论文做了哪些实验？

    作者对n8n展开三轮绕过测试获得三项CVE（CVSS 9.4至9.5），测得AST覆盖率为35%，并完成端到端凭据拦截验证。

    实验设置

    • 被测系统与组件：深度分析对象为n8n表达式沙箱@n8n/tournament（VariablePolyfill组件）及n8n多步表单节点（Form.node.ts与utils.ts）；架构对比对象包括Apache Airflow（Jinja2）、Retool、LangChain.js（expr-eval）、Zapier（AWS Lambda）。
    • 数据集与规范基准：ECMAScript ESTree规范（ECMA-262第15版，共72个AST节点类型）及Babel AST / ast-types类型定义。
    • 辅助生成模型：未指定具体模型名称与版本的LLM（用于针对未处理AST节点自动化生成候选绕过表达式）。
    • 指标定义：处理节点数（Handled node types）、规范节点数（ESTree spec node types）、未处理节点数（Unhandled node types）、AST覆盖率（Coverage ratio）、CVSS v4.0评分。
    • 判定与验证方式：静态AST覆盖率比对、本地与端到端真实部署环境下的RCE PoC利用验证、凭据解密与反向代理流量拦截验证。
    • 样本量与重复次数：针对ESTree全部72个节点类型进行覆盖分类；对n8n进行三轮漏洞挖掘与补丁响应追踪（涉及3个CVSS 9.4-9.5的CVE）；论文未报告LLM生成测试的样本条数与重复试验次数。

    主结果

    三轮漏洞挖掘与逃逸验证的主结果如下（据Section 3.2、3.3、4.1与Table A.1）：

    表格较宽，可左右滑动

    CVE编号绕过轮次攻击向量CVSS评分认证要求突破发生阶段
    CVE-2026-25049Round 1 & 1.5TaggedTemplate + ODP9.4需认证AST重写阶段
    CVE-2026-27577Round 2SpreadElement9.4需认证编译阶段
    CVE-2026-27493Round 3Form节点双重求值9.5无需认证多阶段求值组合
    • 针对性补丁被快速绕过：作者报告n8n在Round 1后48小时内发布了PR #23560修复模板字面量，但4天后即被Object.defineProperty绕过；随后n8n在v2.4.0发布了包含9项安全加固的完整方案，但仍被Round 2的单行表达式完全突破。
    • 编译期逃逸使运行时防御完全失效：作者指出Round 2的SpreadElement漏洞发生在AST重写阶段，由于未生成正常的沙箱包装，v2.4.0新增的9项运行时检查（PrototypeSanitizer、FunctionThisSanitizer等）均未被执行。
    • 双重求值破坏认证边界：作者指出CVE-2026-27493是逻辑双重求值缺陷，攻击者无需登录即可利用公开的/form/*端点提交载荷并触发RCE，CVSS评分达9.5。

    AST规范覆盖率量化分析与AI辅助枚举

    • 测了什么：对@n8n/tournament中的VariablePolyfill进行AST规范覆盖率度量，比对ESTree规范的72种节点类型，并使用LLM针对未处理节点生成测试用例（Section 5.2、Figure 6、附录 C.5）。
    • 结果：沙箱仅处理了25个节点类型，覆盖率为35%（25/72），剩余47个未处理节点类型（占65%）。未处理节点中，Critical级别2个（SpreadElement、RestElement），High级别4个（YieldExpression、AwaitExpression等），Medium级别10个，Low级别31个。通过LLM辅助枚举直接发现了CVE-2026-27577。
    • 作者的解读：作者称35%的覆盖率表明沙箱存在47个潜在绕过向量；借助LLM生成和测试候选表达式，使穷举47个潜在向量的时间从数月缩短至数小时，消除了传统枚举沙箱依赖缺口隐蔽性的假设。

    端到端AI基础设施利用链验证

    • 测了什么：在实际n8n部署环境中测试从外部无认证请求到持久化拦截大模型API调用的完整攻击链（Section 4.3、Figure 5）。
    • 结果：通过表单端点注入实现RCE后，成功读取进程环境变量N8N_ENCRYPTION_KEY；利用AES-256-CBC和弱KDF解密credentials_entity表；将AI服务商的baseUrl篡改为反向代理地址后写回数据库。代理成功截获API密钥及Prompt请求，工作流正常完成且监控全绿，重启后攻击依然生效。
    • 作者的解读：作者称每个节点单独审视均表现正常，但组合后的流水线通过信任清洗使恶意输入获得了凭据级执行权限；因为入侵发生在所有检查的上游，下游监控无法检出。

    跨平台沙箱失效与架构隔离对照

    • 测了什么：调研编排领域的其他沙箱实现与失效案例（Section 2.3、Section 7.3）。
    • 结果：Jinja2的SandboxedEnvironment在CVE-2024-56326修复后又出现CVE-2025-27516绕过；Retool在2025年7月披露同进程沙箱逃逸；expr-eval曝出CVE-2025-12735；Zapier虽采用Lambda进程隔离，但2022年的ZAPESCAPE攻击利用了账户内共享Lambda的缺陷，在改为每用户实例后成功缓解。
    • 作者的解读：作者称这表明枚举拦截沙箱在整个产品类别中均存在结构性失效；而Zapier的案例表明进程级隔离能够生效，关键在于隔离边界的架构设计。

    其他消融与分析

    • ESTree节点覆盖率：处理25种，未处理47种，总计72种，覆盖率35%（Figure 6）
    • 未处理AST节点严重度分布：Critical 2项，High 4项，Medium 10项，Low 31项（附录 C.5）
    • 补丁响应周期：n8n在24-48小时内确认报告，首轮补丁PR #23560于48小时内发布（附录 B）
    • v2.4.0加固覆盖范围：发布9项针对性安全修复，全部位于运行时层（Section 3.3、附录 B.1）
    • 社区独立复现规模：3个月内4个以上独立研究团队报告了6个以上n8n表达式沙箱CVE（Section 7.3）
    • 语言静态检查盲区：ast-types中SpreadElement未归入ExpressionKind等联合类型，TypeScript判定switch穷尽，导致未处理节点静默落入default（附录 A.3）

  5. 有什么可以进一步探索的点？

    作者指出了将组合怪异机扩展至LLM随机组件、开展跨平台验证以及策略反转无法替代运行时隔离等局限与后续方向。

    作者指出的局限与后续方向

    • 包含随机组件的组合怪异机（Section 7.3）：作者指出本文的组合扩展仅覆盖了确定性表达式引擎之间的组合；未来的自然延伸是研究当流水线中包含大语言模型（LLM）处理自然语言等随机组件时，是否会产生超出单一组件能力的突现攻击面。
    • 跨平台分析与工具验证（Section 7.3）：作者指出本文的深度案例研究是n8n，邀请研究社区将AST覆盖率分析方法与工具应用到其他编排平台并发布结果。
    • 策略反转无法替代运行时隔离（Section 6.2）：作者指出策略反转并不能消除对运行时隔离的需求；攻击者若在允许的节点类型组合中找到可利用逻辑仍可能逃逸，因此策略反转必须与运行时进程隔离互补。
    • 未处理AST节点的实证测试缺口（Section 5.2与附录 C.5）：作者指出除已证实的SpreadElement外，其余46个未处理AST节点尚未逐一进行单独的漏洞利用测试，目前的严重度分类仅反映静态AST分析而非确认的利用。
    • 双重求值消除的范围局限（Section 6.2与附录 B.2）：作者指出PR #26214仅移除了Form节点中prepareFormFields的二次求值，但平台中其他可能存在多阶段求值的节点与组件仍需要全面审计与消除。

    实验覆盖范围

    • 被测编排系统以n8n（@n8n/tournament、nodes-base）为核心深度实证对象，对照分析覆盖Jinja2（Airflow）、Retool、expr-eval（LangChain.js）与Zapier共5个平台（Section 2.3、Section 7.3）。
    • AST规范覆盖率度量基于ECMAScript ESTree规范的72个节点类型，实证验证了@n8n/tournament中25个已处理节点与47个未处理节点（Section 5.2、附录 C.5）。
    • 漏洞实证涵盖三轮绕过（CVE-2026-25049、CVE-2026-27577、CVE-2026-27493），并在受控测试环境中完成了6步端到端利用链验证（Section 3、Section 4.3、附录 A）。
    • 论文未报告利用LLM辅助枚举未处理节点时的具体LLM模型名称、版本、提示词结构及生成测试的耗时（Section 5.4）。
    • 论文未报告端到端攻击链中反向代理增加延迟的具体测量毫秒数值与方差统计数据（Section 4.3）。

  6. 总结一下论文的主要内容

    作者提出编排层怪异机理论与AST覆盖率工具，通过三轮绕过阐明枚举沙箱缺陷，倡导策略反转与进程隔离。

    本文针对AI工作流编排系统的表达式沙箱安全性展开系统研究，揭示了其依赖枚举黑名单导致的安全失效机制。

    • 核心问题与场景：在n8n等主流编排平台中，用户表达式求值引擎、敏感凭据库与工作流运行时紧密耦合在同一系统进程中；攻击者一旦实现表达式引擎的沙箱逃逸，便能直接获取解密密钥并完全接管所有被连接的云端服务与AI大模型接口。
    • 理论框架与机制分析：作者将表达式沙箱建模为指令集不断随语言规范扩充的怪异机；提出在多阶段流水线中，未受信任的外部输入通过信任清洗在各节点间逐级被抹去污点标记，最终使恶意输入在无需认证的情况下驱动受凭据保护的高权限操作。
    • 实证攻击与利用链验证：在对n8n的多轮实际攻击测试中，作者发现了三组关键漏洞：针对模板字面量与原型操纵的CVE-2026-25049（CVSS 9.4）、利用展开语法在编译期规避全部9项运行时防御的CVE-2026-27577（CVSS 9.4），以及利用表单二次求值实现的未认证远程代码执行漏洞CVE-2026-27493（CVSS 9.5）；并构建了透明反向代理，实现了发往OpenAI等大模型调用凭据的持久化静默劫持。
    • 攻击面量化与自动化工具：作者构建了针对ECMAScript语言ESTree规范的AST覆盖率量化分析方法与配套开源工具；度量显示n8n表达式沙箱仅覆盖了72个语法节点中的25个，覆盖率仅为35%，存在47个潜在绕过向量，且借助LLM辅助生成可在数小时内完成所有未覆盖节点的绕过测试。
    • 防御结论与架构启示：作者指出基于AST重写与运行时黑名单的枚举防御在结构上无法抵御语言演进；防御体系必须进行策略反转（改用仅允许必要节点类型的最小允许列表），并结合以V8隔离区或独立容器为代表的进程级运行时强隔离，同时在架构层面将凭据管理与表达式计算拆分为不同进程。
阅读原文arxiv.org