2026年——开源工作流自动化平台n8n被披露存在一个CVSS 3.1评分9.9的关键漏洞（CVE-2026-25049）：拥有工作流创建权限的已认证用户可以构造恶意JavaScript表达式，绕过平台的表达式求值沙箱，在宿主服务器上执行任意系统命令。OPSWAT渗透测试团队对该漏洞的完整技术分析揭示了其精妙之处——攻击仅凭JavaScript解构赋值语法与箭头函数的组合，就同时击穿了n8n部署的全部五层安全防御。
漏洞背景与影响范围
n8n是广受欢迎的开源工作流自动化平台，提供超过1300个集成，被开发团队与企业用于自动化从内部工具到关键业务数据管道的各类流程。其架构以节点为基础：工作流由互联节点组成，以JSON格式在触发器、动作与函数步骤间传递数据。
该漏洞影响1.123.17之前的所有版本以及2.0.0至2.5.1版本，已在1.123.17与2.5.2中修复。其严重性在于n8n在组织基础设施中的特权位置：作为自动化中枢，n8n通常直接持有内部API、数据库、凭证存储与第三方服务的访问权。一个失陷的n8n实例暴露的不只是自动化服务器本身，而是通向所有已连接系统的跳板。
值得注意的是，CVE-2026-25049并非孤立发现，而是对CVE-2025-68613（n8n表达式求值器早期沙箱逃逸漏洞）补丁的绕过。尽管初版漏洞后实施了多层防御，但净化器处理JavaScript抽象语法树（AST）节点类型时的根本缺陷，使同类攻击通过另一种语法载体卷土重来。
五层防御与它们的共同盲区
n8n允许用户在工作流节点参数中嵌入JavaScript表达式，由名为Tournament的库在服务端解析为AST后执行。由于表达式与n8n服务器运行在同一Node.js进程中，平台部署了五层安全机制：
- 全局上下文覆盖：求值前将document、window、globalThis、eval、setTimeout、Function等危险全局对象替换为空对象；
- 正则校验：对原始表达式字符串执行正则检查，拦截点号访问.constructor属性；
- PrototypeSanitizer（AST运行时净化器）：在AST构建时遍历MemberExpression节点，对照黑名单检查constructor、原型对象等危险属性；
- FunctionThisSanitizer：拦截立即调用函数表达式（IIFE），将其this绑定到空对象，封堵通过未绑定this引用泄露全局process对象的原利用路径；
- 上下文属性移除：从执行上下文中移除或覆盖eval、Function、process.mainModule等属性。
五层防御共享同一个假设：属性访问只会通过点号（obj.constructor）或方括号语法发生。没有任何一层考虑过JavaScript解构赋值语法。
攻击路径：三步击穿全部防御
OPSWAT团队复现的利用链展示了惊人的简洁性：
第一步：箭头函数入口。载荷以包裹在IIFE中的箭头函数开头。FunctionThisSanitizer只检查callee是否为FunctionExpression节点，而箭头函数产生ArrowFunctionExpression节点，净化器直接提前返回不做重写。箭头函数从词法作用域继承this，天然获得未净化的全局上下文访问。
第二步：解构赋值绕过。在箭头函数内部，用解构赋值从函数实例中提取Function构造器：const { constructor } = () => {};。这产生的是ObjectPattern节点而非MemberExpression节点——正则看不到.constructor模式，PrototypeSanitizer从不检查该属性名。攻击者就此拿到Function构造器引用。
第三步：动态代码执行。利用Function构造器构造并执行任意代码，动态构造的函数在沙箱上下文之外运行，完整访问Node.js的process对象，进而加载Node.js的子进程执行模块，实现宿主机上的任意系统命令执行。
同一个语义操作（访问对象属性）在不同语法下产生完全不同的AST结构——obj.constructor产生MemberExpression，而const { constructor } = obj产生包含ObjectPattern与Property节点的VariableDeclaration。净化器只检查前者，这就是整个漏洞的钥匙。
Webhook升级：从认证RCE到无认证攻击
该漏洞的危险性在与n8n的webhook功能结合后成倍放大。n8n允许工作流将HTTP端点暴露为webhook，认证选项包括bearer令牌、基本认证——以及完全不设认证。
拥有工作流创建权限的攻击者可以配置一个认证为“none”的公开webhook，在相连节点中嵌入RCE载荷并激活工作流。此后，来自互联网任何位置的任意HTTP请求都会触发宿主机上的任意命令执行。这条升级路径将CVE-2026-25049从已认证的内部漏洞，转变为暴露面覆盖整个互联网的事实上的无认证攻击向量。
修复与防御建议
n8n官方已在1.123.17与2.5.2版本中修复该漏洞，方式是在净化函数中实现正确的运行时类型检查，并将AST覆盖范围扩展到解构赋值模式。对无法立即升级的部署，建议：
- 将工作流创建与编辑权限严格限制于完全受信的用户；
- 在加固环境中部署n8n，限制操作系统权限与网络访问；
- 审计现有工作流中的可疑表达式；
- 监控源自n8n进程的异常系统命令执行；
- 重点审查所有未设认证的webhook端点配置。
这起漏洞给安全工程的核心教训在于：当防御建立在语法模式黑名单之上时，一门图灵完备语言所提供的表达同一语义的路径数量，永远比黑名单更长。修补特定利用技术而非底层设计弱点，只会让同类漏洞换个语法再次现身。