文章总结： n8n曝出严重RCE漏洞CVE-2025-68613，CVSS评分9.9。因沙箱隔离失效，认证用户可突破限制获取process对象，执行任意系统命令或窃取密钥。受影响版本广泛且全球大量实例暴露。建议立即升级至1.120.4以上版本，或通过限制权限、网络隔离等措施进行临时缓解，防范服务器被控。 综合评分： 88 文章分类： 漏洞分析,漏洞预警,解决方案

你的自动化工作流可能正在“帮”黑客挖矿：深扒 n8n 远程代码执行漏洞 (CVE-2025-68613)

原创

Hankzheng

技术修道场

2025年12月26日 07:53 广东

在这个“低代码”横行的时代，n8n 凭借其强大的节点生态和可视化的工作流编排，绝对算得上是我们技术人手中的“瑞士军刀”。我自己就用它搭了不少自动化任务，从监控报警到数据同步，简直不要太爽。

但是，兄弟们，今天这篇推文不是来安利的，而是来救火的。

就在这几天，n8n 官方披露了一个代号为 CVE-2025-68613 的严重安全漏洞。你知道它的 CVSS 评分是多少吗？9.9分！（满分10分）。

如果不抓紧处理，你那台辛辛苦苦配置的自动化服务器，可能分分钟就成了黑客手中的玩物。

今天，咱们就脱去枯燥的官方通告外衣，用技术的视角来扒一扒：这个漏洞到底是怎么发生的？为什么它如此危险？以及，我们该怎么办？

01 发生了什么？

简单来说，n8n 曝出了一个 任意代码执行 (Arbitrary Code Execution) 漏洞。

这个漏洞是由安全研究员 Fatih Çelik 发现并报告的。根据 npm 的统计，n8n 包的周下载量高达 5.7 万次，这意味着潜在的受害者数量极其庞大。

官方给出的描述很简短，但字字惊心：

“Under certain conditions, expressions supplied by authenticated users… may be evaluated in an execution context that is not sufficiently isolated…”

翻译成人话就是：通过认证的用户在配置工作流时，如果输入了特定的表达式，这些表达式可能会突破原本的限制，直接在服务器的底层运行时环境中执行。

02 硬核解析：当“笼子”关不住“老虎”

为了让大家理解这个漏洞的技术原理，我们需要聊聊 n8n 的核心机制。

n8n 之所以强大，很大程度上是因为它允许我们在节点中使用 JavaScript 表达式 来处理数据。为了安全起见，这些代码通常不会直接在你的 Node.js 主进程中裸奔，而是会被放进一个 “沙箱” (Sandbox) 或者隔离的上下文中运行。

想象一下，你作为一个开发者，给用户提供了一个在线编写代码的功能。你肯定不希望用户写一句 require('child_process').exec('rm -rf /') 把你的服务器删光，对吧？所以你会给代码执行环境套上层层枷锁，禁止它访问系统级 API。

然而，CVE-2025-68613 恰恰就是这个“枷锁”失效了。

技术痛点：上下文隔离失败

在 Node.js 环境下，实现完美的沙箱隔离一直是个技术难题（比如经典的 vm2 逃逸历史）。

这次 n8n 的问题在于，当处理用户输入的表达式时，执行上下文（Execution Context）没有完全切断与宿主环境（Host Runtime）的联系。

• 攻击向量

  攻击者只需要拥有“配置工作流”的权限（Authenticated User）。

• 利用手段

  在输入框中构造特殊的 JavaScript 对象或原型链调用（Prototype Pollution 可能是潜在的跳板之一）。

• 结果

  由于隔离不充分，攻击者可以获取到 n8n 进程的 process 对象。

一旦拿到了 process 对象，对于我们懂技术的人来说，意味着什么不言而喻：

🔴 读取环境变量：process.env 里可能存着你的 AWS 密钥、数据库密码。 🔴 执行系统命令：利用 child_process 模块，攻击者可以执行任意 Shell 命令，安装后门、反弹 Shell、甚至部署挖矿脚本。

这就是为什么它被打到了 9.9 分。 只要攻击者能登录你的 n8n 面板（或者你通过某些方式暴露了配置接口），他们就能获得服务器的 Root 级控制权。

03 全球 10 万实例，你在其中吗？

这个漏洞的影响范围非常广。根据攻击面管理平台 Censys 截止到 12月22日 的数据：

• 🌍 全球有 103,476 个潜在的受影响实例暴露在公网。
• 📍 重灾区主要集中在 美国、德国、法国、巴西和新加坡。

虽然国内的数据没有具体列出，但我知道咱们很多团队都在用 n8n 做私有化部署。如果你的实例直接暴露在公网，且没有做严格的访问控制，现在就像是在裸奔。

⚠️ 受影响版本范围：

= 0.211.0 且 < 1.120.4

基本上，只要你最近半年没更新过 n8n，大概率都中招了。

04 止损：Show Me The Solution

哪怕是为了今晚能睡个安稳觉，我也建议你立刻、马上采取行动。

方案一：升级（强烈推荐）

官方已经紧急发布了补丁版本，请根据你的当前环境，升级到以下任一版本或更高： 1.120.4、1.121.1 或 1.122.0

如果你是用 Docker 部署的（绝大多数人应该都是），一条命令的事：

# 生产环境建议指定具体Tag，例如 n8nio/n8n:1.122.0
docker pull n8nio/n8n:latest
docker-compose up -d

方案二：临时缓解（Defense in Depth）

如果因为业务原因暂时无法升级（毕竟年底了，封板期谁都不想动生产环境），你必须做好以下纵深防御：

1. 收紧权限

   既然漏洞利用的前提是“认证用户”，那就严格限制谁能创建和编辑工作流。把那些不活跃的账号先停了。

2. 网络隔离

   千万别把 n8n 直接暴露在公网！配合 VPN 或内网穿透使用，或者在 Nginx 层加个 Basic Auth 多一层防护。

3. 最小权限原则

   检查运行 n8n 容器的用户权限。不要用 root 运行容器！

技术工具的便利性往往伴随着安全风险。n8n 这次翻车也再次提醒了我们：不要过度信任内网工具的安全性。

很多时候，我们把防火墙对外防得死死的，却忽略了像 n8n 这种拥有强大执行能力的内部系统，一旦失守，那就是直接把“家门钥匙”交给了黑客。

别犹豫了，转给你的运维同事，赶紧检查一下版本号吧！

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：技术修道场 Hankzheng《你的自动化工作流可能正在“帮”黑客挖矿：深扒 n8n 远程代码执行漏洞 (CVE-2025-68613)》