在低代码自动化浪潮下，n8n 作为一款开源、可扩展的工作流自动化工具，凭借其灵活的节点配置、多平台集成能力，已广泛应用于企业级自动化场景——从数据同步、API 调度到业务流程自动化，成为许多团队提升效率的核心工具。然而，近期披露的 CVE-2025-68613 高危漏洞，却撕开了这款工具的安全防线：一个看似不起眼的表达式注入漏洞，结合沙箱逃逸，可直接实现 Node.js 远程代码执行（RCE），攻击者甚至能以未授权身份接管整个 n8n 服务，窃取敏感配置、控制业务流程，给企业带来致命安全风险。
本文将从漏洞背景、技术原理、完整攻击链实战、修复方案四个维度，全方位拆解 CVE-2025-68613 的利用逻辑，同时结合当前低代码工具的安全共性问题，给出前瞻性防御建议，帮助企业快速识别风险、构建安全防护体系。
CVE-2025-68613 是一个存在于 n8n 中的高危远程代码执行漏洞，其核心成因是表达式解析环节的沙箱隔离不严格，导致攻击者可通过注入恶意表达式，绕过沙箱限制执行任意 Node.js 代码。该漏洞被赋值 CVSS 评分 8.8（高危），属于“易利用、高危害”类型，且影响范围覆盖绝大多数正在使用的 n8n 版本。
要理解 CVE-2025-68613 的攻击链，首先需要明确 n8n 的核心工作机制：n8n 允许用户通过“表达式（Expression）”自定义工作流逻辑，例如在节点中通过 n8n 工作流 教程 读取数据，或通过表达式实现条件判断、数据转换。这些表达式会被 n8n 底层解析并执行，而其为了防止恶意代码执行，引入了 vm2 库构建沙箱环境，限制表达式的执行范围——理论上，沙箱内的代码无法访问 Node.js 主进程的核心模块（如 child_process、fs），也无法操作系统资源。
但 CVE-2025-68613 恰恰利用了“表达式输入校验缺失”与“vm2 沙箱逃逸”两个漏洞的叠加，形成了完整的 RCE 攻击链，其核心逻辑可拆解为三个关键环节，每个环节都存在明确的安全短板。
（一）入口突破：表达式注入的可利用场景（低门槛攻击前提）
n8n 的表达式输入场景极为广泛，且多数场景未对用户输入做严格限制，这为攻击者提供了便捷的注入入口。无论是授权用户还是未授权用户，都可通过以下场景注入恶意表达式，且无需复杂的技术门槛：
- 工作流节点直接注入：在“Function”“Set”“Filter”等核心节点中，用户可直接输入表达式（格式为 ），n8n 会实时解析执行该表达式。攻击者只需在输入框中填入恶意代码，即可完成注入。
- 恶意工作流导入：n8n 支持导入 JSON 格式的工作流配置文件，攻击者可预先构造含恶意表达式的工作流 JSON，通过“导入工作流”功能上传，导入后无需额外操作，只要运行该工作流，恶意表达式就会被执行。
- API 接口注入：n8n 提供了完整的 REST API，用于创建、编辑工作流。攻击者可通过调用 接口，在请求体中传入含恶意表达式的节点配置，实现远程注入，无需登录后台（若未开启认证）。
- 间接注入场景：即使限制了“Function”节点的使用，攻击者仍可通过“Webhook”节点接收外部数据，将恶意表达式伪装成正常数据传入，再通过其他节点的表达式解析功能触发漏洞。
值得注意的是，n8n 默认部署时未开启认证功能，任何人都可访问后台编辑工作流——这意味着，公网可访问的 n8n 服务，几乎处于“无防护”状态，攻击者可直接注入恶意表达式，无需任何权限绕过。
（二）核心突破：vm2 沙箱逃逸（RCE 的关键环节）
n8n 依赖 vm2 库（版本 < 3.9.19）构建表达式执行沙箱，而该版本的 vm2 存在一个经典的沙箱逃逸漏洞（CVE-2023-30547 的衍生漏洞），攻击者可通过构造特殊代码，突破沙箱隔离，获取 Node.js 主进程的 能力——这是实现 RCE 的核心一步。
vm2 沙箱的核心设计目标是“隔离代码执行环境”，禁止沙箱内代码访问主进程的 对象、核心模块等敏感资源。但该漏洞的存在，使得攻击者可通过“原型链污染+process 对象泄露”的方式，绕过沙箱限制：
- 沙箱逃逸原理：vm2 沙箱在处理表达式时，未完全阻断对 对象的间接访问，攻击者可通过 获取主进程的模块对象，再通过 方法加载 Node.js 核心模块（如 child_process、fs），从而突破沙箱限制。
- 简化版逃逸代码解析：
这里需要强调的是，vm2 沙箱逃逸并非 n8n 独有问题——许多基于 Node.js 开发的低代码工具、自动化平台，都依赖 vm2 实现沙箱隔离，若未及时升级 vm2 版本，都可能面临类似的沙箱逃逸风险，这也是 CVE-2025-68613 带来的行业警示。
（三）最终落地：RCE 完整利用（接管目标系统）
当攻击者通过沙箱逃逸获取 能力后，即可调用 Node.js 核心模块，执行任意系统命令，实现完整的 RCE，其利用场景可分为三类，覆盖从信息窃取到系统接管的全流程：
- 系统命令执行：通过 child_process 模块执行 （查看当前用户权限）、（查看目录文件）、（查看网络连接）等命令，收集目标系统信息；若获取 root 权限，可直接执行系统管理命令（如 、）。
- 反弹 Shell 接管：这是最危险的利用方式，攻击者构造反弹 Shell 命令（如 ），执行后可获取目标系统的交互式 Shell，实时控制目标机器，窃取敏感数据、植入后门。
- 敏感信息窃取与篡改：通过 fs 模块读取 n8n 配置文件（如 ），获取数据库密码、API 密钥、用户凭证等敏感信息；同时可修改工作流配置，植入恶意节点，实现长期控制（如定期执行恶意命令、窃取业务数据）。
为帮助安全从业者、企业运维人员快速识别漏洞风险，本文将基于 Docker 环境，完整复现 CVE-2025-68613 的攻击流程，所有操作仅用于安全测试，请勿用于未授权场景。
（一）环境准备（10分钟快速部署漏洞环境）
- 部署漏洞版本 n8n：使用 Docker 拉取 n8n 1.48.0 版本（漏洞版本），执行命令：
- 访问漏洞环境：打开浏览器，访问 ，默认无需登录，直接进入 n8n 工作流编辑页面（若出现登录提示，说明部署时开启了认证，需关闭认证后重新部署）。
- 攻击机准备：使用 Kali Linux 作为攻击机，开启监听端口（用于反弹 Shell），执行命令：
（二）恶意表达式构造（核心步骤，避坑要点）
攻击者需构造符合 n8n 表达式格式的恶意代码，同时确保代码能绕过沙箱、执行目标命令。这里以“反弹 Shell”为例，构造完整的恶意表达式：
避坑要点：1. 需用 try-catch 包裹代码，避免执行失败时暴露恶意代码；2. 反弹 Shell 命令需根据目标系统调整（Windows 系统使用 powershell 命令，Linux/Mac 使用 bash 命令）；3. 表达式格式必须严格遵循 ，否则无法被 n8n 解析。
（三）漏洞触发与 RCE 验证（全程无难点）
- 新建工作流：在 n8n 后台，点击“New Workflow”，创建空白工作流。
- 添加恶意节点：拖拽“Function”节点到工作流中，双击节点，将上述恶意表达式粘贴到“Function Code”输入框中，点击“Save”保存。
- 触发漏洞：点击工作流顶部的“Run”按钮，执行该工作流。此时，恶意表达式会被 n8n 解析执行，目标机器会主动连接攻击机的 9999 端口。
- 验证 RCE 结果：查看攻击机的监听窗口，会显示“connect to [攻击机IP] from [目标机IP]”，此时已获取目标机器的交互式 Shell，执行 命令可查看当前用户权限（默认 n8n 容器以 root 权限运行）：
（四）实战延伸：未授权注入与批量利用思路
若目标 n8n 服务开启了认证，攻击者可通过以下方式突破权限限制：1. 利用 n8n 其他弱口令、权限绕过漏洞获取登录凭证；2. 诱导授权用户导入恶意工作流（如伪装成“常用工作流模板”）。
对于批量部署 n8n 的企业，攻击者可通过端口扫描（扫描 5678 端口）识别漏洞版本实例，再通过 API 接口批量注入恶意表达式，实现大规模攻击——这也是该漏洞的高危之处：不仅易利用，还可快速扩散。
针对 CVE-2025-68613，n8n 官方已在 1.49.0 版本中完成修复，核心修复方向是“强化表达式校验+升级沙箱依赖”。企业需结合自身部署场景，采取“紧急修复+长期防御”的双重策略，彻底规避漏洞风险。
（一）紧急修复措施（立即执行，阻断攻击）
- 版本升级（最核心）：立即将 n8n 升级到 1.49.0 及以上版本，官方已修复表达式校验逻辑，同时将 vm2 升级到 3.9.19+（修复沙箱逃逸漏洞）。升级命令（Docker 部署）：
`# 停止旧版本容器
docker stop $(docker ps -a | grep n8n | awk ‘{print $1}’)
docker run -it –rm -p 5678:5678 n8nio/n8n:1.49.0`
- 开启认证（阻断未授权访问）：即使升级版本，也需开启 n8n 认证，避免未授权用户访问后台。通过环境变量设置认证：
建议使用强密码，并定期更换。
- 临时拦截（无升级条件时）：若暂时无法升级，可部署 WAF，拦截含 、、 等敏感关键词的表达式输入；同时禁用“Function”节点，限制表达式的使用场景。
（二）长期防御策略（构建完整防护体系）
CVE-2025-68613 并非个例，其暴露的“表达式注入+沙箱逃逸”问题，是低代码工具、自动化平台的共性安全隐患。企业需从“输入校验、沙箱加固、权限管控、日志审计”四个维度，构建长期防御体系：
- 输入校验加固：对所有表达式输入做严格的白名单过滤，禁止使用 、、 等敏感对象/模块；限制表达式的语法范围，仅允许使用数据读取、简单运算等安全操作。
- 沙箱方案优化：放弃存在安全隐患的 vm2 库，改用更安全的沙箱方案（如 isolated-vm），强化沙箱隔离能力，禁止沙箱内代码访问主进程资源；定期更新沙箱依赖，及时修复沙箱漏洞。
- 权限最小化管控：实行“最小权限原则”，n8n 进程以非 root 用户运行；细分用户权限，仅给必要人员分配“工作流编辑权限”，禁止普通用户使用“Function”等高危节点；限制 n8n 容器的网络访问，禁止其访问公网敏感端口、内部数据库。
- 日志审计与监控：开启 n8n 详细日志，监控表达式执行行为，及时发现异常命令调用、沙箱逃逸尝试；部署安全监控工具，对 n8n 的 API 接口、工作流执行记录进行实时监控，一旦发现恶意注入行为，立即阻断并告警。
- 定期安全检测：定期扫描 n8n 部署实例，排查是否存在未升级版本、弱口令、恶意工作流等问题；定期开展渗透测试，模拟攻击者视角，发现潜在安全隐患。
随着低代码、自动化工具的普及，类似 CVE-2025-68613 的漏洞频发——本质上，这是“灵活性与安全性的矛盾”：工具为了提升易用性，开放了更多自定义能力（如表达式、脚本编辑），但同时也引入了注入、逃逸等安全风险。结合 CVE-2025-68613，我们可以预见未来低代码工具的安全防御方向：
- 沙箱技术升级：传统沙箱（如 vm2）已无法满足安全需求，未来将出现更轻量、更安全的沙箱方案，结合硬件虚拟化、容器隔离等技术，实现更严格的代码隔离，从根本上杜绝沙箱逃逸。
- 智能风控与异常检测：通过 AI 算法对表达式、脚本输入进行实时分析，识别恶意代码特征，提前阻断注入攻击；对工作流执行行为进行基线建模，一旦出现异常（如执行系统命令、访问敏感文件），立即告警并拦截。
- 安全左移与开发规范：低代码工具厂商需将安全融入开发全流程，在功能设计阶段就考虑注入、逃逸等风险，制定严格的表达式解析规范；同时为用户提供安全配置指南，引导用户开启认证、权限管控等防护措施。
- 漏洞响应机制优化：建立更快速的漏洞披露与修复机制，厂商需及时响应漏洞报告，发布修复版本；企业需建立漏洞应急响应流程，一旦发现漏洞，可快速升级、拦截，减少攻击损失。
CVE-2025-68613 是一个典型的“低门槛、高危害”漏洞，其完整攻击链（表达式注入→沙箱逃逸→RCE）暴露了 n8n 在安全设计上的短板，也为所有使用低代码、自动化工具的企业敲响了警钟。对于企业而言，当前最紧急的任务是升级 n8n 版本、开启认证，阻断漏洞利用路径；长期来看，需建立完善的安全防护体系，平衡工具的灵活性与安全性。
值得注意的是，漏洞的危害不仅在于“远程代码执行”，更在于其可扩散性——公网中存在大量未升级、未开启认证的 n8n 实例，攻击者可通过批量扫描实现大规模攻击。因此，企业需提高安全意识，定期开展安全检测，及时修复漏洞，避免因一个小漏洞引发系统性安全风险。
未来，随着低代码技术的不断发展，安全防护将成为企业数字化转型的核心需求。唯有重视每一个细节漏洞，构建全方位的防御体系，才能在享受自动化带来的效率提升的同时，守住安全底线。
发布者：全栈程序员-站长，转载请注明出处：https://javaforall.net/273967.html原文链接：https://javaforall.net
