n8n高危漏洞深度剖析：认证绕过与RCE攻击链的修复与加固

2026/6/28 23:06:48

1. 项目概述：一次对n8n自动化平台高危漏洞的深度剖析

最近在安全圈和自动化运维领域，一个组合漏洞引起了不小的震动。CVE-2026-21858 和 CVE-2025-68613，这两个编号指向了当下非常流行的开源工作流自动化工具 n8n。我注意到很多团队，无论是初创公司还是大型企业的内部自动化流程，都在使用 n8n 来串联各种服务，从简单的数据同步到复杂的业务逻辑处理，它几乎成了低代码/无代码自动化领域的瑞士军刀。然而，这次曝出的漏洞链，其严重性被评定为“高危”甚至“严重”，意味着攻击者有可能通过精心构造的请求，完全接管你的 n8n 实例，进而控制所有已连接的服务和数据管道。这绝不是危言耸听，对于一个核心业务流程依赖 n8n 的组织来说，这等同于把后门钥匙放在了互联网上。

我自己在搭建和维护内部自动化平台时，也深度使用过 n8n。它的确极大地提升了效率，但正因为其强大的集成能力和相对便捷的部署方式（尤其是 Docker 部署），安全配置往往容易被忽视。这次漏洞的曝光，正好给我们所有使用者敲响了警钟。本文将不仅仅是对这两个 CVE 编号的简单复述，我会结合对 n8n 架构的理解和实际的安全评估经验，深入拆解漏洞的原理、复现条件、潜在影响范围，并给出详尽的修复与加固方案。无论你是正在评估 n8n 的安全工程师，还是负责运维 n8n 实例的开发者，甚至是刚刚接触自动化、想用 n8n 做个网页爬虫或调用 Minimax 模型的个人用户，理解这些风险都至关重要。

2. 漏洞核心原理与影响范围深度解析

在深入细节之前，我们首先要明确 n8n 是什么。简单来说，n8n 是一个基于节点的可视化工作流自动化工具。你可以把它想象成一个更强大、更开发友好的 IFTTT 或 Zapier，但它可以部署在你自己的服务器上。用户通过拖拽不同的“节点”（比如 HTTP 请求节点、数据库节点、AI 模型调用节点等），并用线条连接它们，来定义自动化流程。这些工作流可以由 HTTP 请求、定时器或 webhook 触发。由于其开源和自托管的特性，n8n 在处理敏感数据和企业内部集成时备受青睐。

2.1 CVE-2025-68613：身份验证绕过与权限提升的突破口

我们先来看 CVE-2025-68613。这个漏洞的核心是一个身份验证绕过问题。在 n8n 的架构中，为了执行工作流，需要有一个执行上下文。这个上下文包含了当前执行用户的身份和权限。n8n 提供了多种身份验证方式，包括基础的 API 密钥、OAuth 以及面向企业版的 LDAP 等。

漏洞出现在 n8n 处理某些特定类型的请求或工作流配置时，对执行上下文的身份验证检查存在逻辑缺陷。攻击者可以构造一个特殊的请求，该请求能够欺骗 n8n 的认证中间件，使其误认为该请求来自一个已通过认证的、具有高权限的用户（例如实例的所有者或管理员），而不是一个匿名或低权限用户。

技术细节浅析：这可能涉及到请求路径的处理、特定 HTTP 头的注入、或者工作流中“Webhook”节点与“HTTP Request”节点联动时的上下文传递错误。例如，攻击者可能通过一个未经验证的外部 Webhook 调用，在后续节点执行时，携带了伪造的或残留的高权限会话令牌，从而以管理员身份执行敏感操作，如读取所有工作流配置、新增或修改工作流、访问连接凭证等。

注意：这里描述的是一种可能的攻击向量。实际利用链可能更复杂，但根本原因在于身份验证边界的不清晰。

影响范围：任何开启了 Webhook 触发功能、或允许外部调用 API 的工作流，如果部署在公网可访问的 n8n 实例上，且未更新到已修复的版本，都可能受此漏洞影响。这意味着，你为微信公众号配置的自动回复机器人、或者那个定时爬取公开数据的爬虫工作流，都可能成为攻击者潜入的入口。

2.2 CVE-2026-21858：远程代码执行的终极武器

如果说 CVE-2025-68613 是打开了大门，那么 CVE-2026-21858 就是登堂入室后拿到系统最高权限的钥匙。这是一个远程代码执行漏洞，通常简称为 RCE。这是安全漏洞中最危险的类型之一，因为它允许攻击者在你的服务器上直接运行任意命令。

在 n8n 的上下文中，RCE 漏洞往往与“自定义代码节点”或某些具有强大功能的节点（如“执行命令”节点，如果安装）有关。n8n 允许用户在“Function”或“Code”节点中编写 JavaScript/Node.js 代码来执行自定义逻辑，这本身提供了极大的灵活性。

漏洞成因：CVE-2026-21858 的根源在于，n8n 对这些用户输入的代码或某些节点参数的处理不当，未能进行充分的沙箱隔离或输入净化。结合 CVE-2025-68613 获得的权限，攻击者可以：

创建一个新的工作流，或在已有工作流中插入一个恶意代码节点。
在该节点中写入能够突破 Node.js 沙箱（如果存在）的 JavaScript 代码。
利用 Node.js 的child_process模块或类似机制，调用系统命令，例如ls、cat /etc/passwd，甚至反弹一个 shell 回连到攻击者控制的服务器。

更危险的场景：即使没有“自定义代码节点”，如果漏洞存在于对工作流 JSON 配置的解析过程中，攻击者可能通过篡改提交的工作流定义数据，在服务器端解析时触发代码执行。这种“反序列化”漏洞在各类应用中屡见不鲜。

影响后果：一旦成功利用，攻击者将完全控制部署 n8n 的服务器。他们可以窃取 n8n 数据库中的所有凭证（这些凭证可能用于连接内部数据库、邮件服务器、云服务 API 等）、篡改或破坏所有自动化流程、以该服务器为跳板攻击内网其他系统，或者植入挖矿木马、勒索病毒等。

2.3 漏洞链的协同效应与严重性评估

单独来看，CVE-2025-68613 和 CVE-2026-21858 都已经足够危险。但当它们组合在一起时，就形成了一条极具破坏力的攻击链：

第一步：潜入。攻击者利用 CVE-2025-68613，无需任何有效凭证，即可绕过登录，获得一个高权限的会话或上下文。
第二步：立足。利用获得的高权限，攻击者可以枚举现有工作流、创建新的工作流，或者修改关键工作流，为代码执行做准备。
第三步：掌控。在创建或修改的工作流中，植入利用 CVE-2026-21858 的恶意代码节点或配置，触发远程代码执行，从而获得服务器的完整控制权。

这个“认证绕过 -> RCE”的链条，使得漏洞利用的门槛和条件大大降低。攻击者从互联网上就可以发起攻击，无需事先窃取密码或 API 密钥。根据 CVSS 评分体系，这类漏洞组合的得分通常会达到 9.0 以上（满分 10.0），属于严重级别。

受影响版本：根据社区和官方通告，受影响的 n8n 版本主要集中在某个范围区间内。例如，n8n 版本号在0.240.0到0.245.1之间（此处为举例，具体版本需查证官方公告）的部署，如果未进行特定安全配置，均可能受到攻击。无论是通过 Docker 安装（docker run -it --rm --name n8n -p 5678:5678 n8nio/n8n），还是直接通过 npm 安装，只要版本落在受影响区间，风险就存在。

3. 漏洞复现与安全验证环境搭建

为了真正理解漏洞的危害并验证修复措施是否有效，在可控环境中进行复现是安全研究的标准做法。我必须强烈强调：以下操作仅应在您个人完全控制的、隔离的实验室环境（如本地虚拟机或独立的云测试实例）中进行。绝对禁止对任何生产环境或他人的系统进行测试，这是违法行为。

3.1 搭建一个用于测试的脆弱 n8n 环境

我们的目标是快速搭建一个包含漏洞的旧版本 n8n，用于分析。

方案一：使用 Docker（最快捷）Docker 是部署 n8n 最流行的方式，也能方便地指定版本。

# 拉取一个已知受影响的旧版本镜像，例如 0.242.0 docker pull n8nio/n8n:0.242.0 # 运行容器，映射端口 5678 docker run -d \ --name n8n-vulnerable \ -p 5678:5678 \ -v n8n_data:/home/node/.n8n \ n8nio/n8n:0.242.0

执行后，访问http://你的服务器IP:5678就能看到 n8n 的初始化设置页面。按照指引完成管理员账户创建。

方案二：使用 npm 安装（更贴近某些生产环境）如果你喜欢直接在系统上安装：

# 安装指定版本 npm install n8n@0.242.0 -g # 启动 n8n n8n start

实操心得：在测试环境，使用 Docker 是更好的选择。测试完毕后，一条docker rm -f n8n-vulnerable命令就能彻底清理，不留痕迹。而 npm 全局安装可能会影响系统其他 Node.js 应用。

3.2 漏洞复现的概念性步骤与核心要点

由于公开披露漏洞的利用细节是极不负责且危险的行为，我这里不会提供具体的攻击载荷。但我可以描述攻击者视角下的关键步骤，这有助于我们理解防御点在哪里：

信息收集：攻击者首先会扫描互联网，寻找开放了 5678 端口（n8n 默认端口）或自定义端口的服务，并通过一些特征判断是否为 n8n。
触发认证绕过：攻击者向目标 n8n 实例的某个特定端点（可能与 REST API、webhook 路径或 GraphQL 接口相关）发送精心构造的 HTTP 请求。这个请求利用了 CVE-2025-68613 的缺陷，使服务器在处理该请求时，错误地将其关联到一个高权限的用户会话。
权限验证：攻击者随后使用同一个会话（或通过该会话获取的令牌），尝试访问本应需要管理员权限的 API，例如GET /api/v1/workflows来列出所有工作流，或POST /api/v1/workflows来创建新工作流。如果成功，则证明认证绕过生效。
植入恶意负载：利用创建或修改工作流的权限，攻击者构建一个包含恶意代码节点的工作流。这个节点的代码会尝试利用 Node.js 环境的特性来执行系统命令（CVE-2026-21858）。
执行与控制：通过触发该工作流（例如，直接调用其 webhook URL 或等待定时触发），恶意代码被执行，攻击者建立远程 shell 连接或执行窃取数据等命令。

关键验证点：在安全测试中，我们关注的是第 2 和第 4 步。能否在未提供合法凭证的情况下，访问到受保护的 API 端点？能否通过 API 创建一个包含child_process.execSync(‘id’)之类代码的 Function 节点并成功返回系统用户信息？

4. 全面修复方案与加固指南

了解漏洞是为了更好地防御。对于正在使用 n8n 的团队和个人，请立即按照以下步骤操作。

4.1 紧急修复：升级到安全版本

这是最根本、最有效的解决方案。n8n 官方在漏洞披露后，会迅速发布修复版本。

确认当前版本：登录你的 n8n 实例，在左下角设置菜单中查看版本号。或者通过 APIGET /api/v1/version获取。
查看官方安全公告：前往 n8n 官方 GitHub 仓库的 “Security Advisories” 页面，或官方博客，查找关于 CVE-2025-68613 和 CVE-2026-21858 的公告。公告中会明确指出修复的起始版本号。

执行升级：

Docker 用户：

# 停止旧容器 docker stop n8n-container-name # 拉取最新安全版本（例如 0.246.0） docker pull n8nio/n8n:latest # 或拉取指定的稳定版本 docker pull n8nio/n8n:0.246.0 # 用新镜像启动容器，保持原有的数据卷映射 docker run -d \ --name n8n-updated \ -p 5678:5678 \ -v n8n_data:/home/node/.n8n \ n8nio/n8n:0.246.0

npm 用户：

npm update n8n -g # 或指定版本 npm install n8n@0.246.0 -g

然后重启 n8n 服务。

验证升级：升级后，再次访问版本信息页面，确认版本号已更新。重新运行你的核心工作流，确保业务功能正常。

注意事项：升级前，务必备份你的 n8n 数据卷（/home/node/.n8n目录）。虽然升级通常很平滑，但备份是应对任何意外的最佳实践。可以使用docker cp命令或直接备份挂载的宿主机目录。

4.2 网络层加固：缩小攻击面

即使打了补丁，将服务暴露在公网也是高风险行为。我们应该实施最小化暴露原则。

禁止公网直接访问：除非绝对必要，否则不要将 n8n 的端口（默认 5678）直接绑定到公网 IP。在 Docker 运行时，使用-p 127.0.0.1:5678:5678仅绑定到本地环回地址。
使用反向代理：如果确实需要从外部访问，务必通过反向代理（如 Nginx, Traefik, Caddy）。
- 添加 HTTPS：配置 SSL 证书，强制所有通信使用 HTTPS，防止中间人攻击和凭证窃取。
- 设置访问控制：在反向代理层配置 HTTP 基本认证、IP 白名单或与现有的单点登录系统集成。
- 示例 Nginx 基础配置片段：
```
server { listen 443 ssl; server_name automation.yourcompany.com; ssl_certificate /path/to/cert.pem; ssl_certificate_key /path/to/key.pem; location / { # IP白名单示例 allow 192.168.1.0/24; allow 10.0.0.0/8; deny all; # 反向代理到本地n8n proxy_pass http://127.0.0.1:5678; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }
```
配置防火墙：在服务器防火墙或安全组规则中，严格限制对 n8n 端口的入站访问，仅允许来自跳板机或内部网络的 IP。

4.3 应用层安全配置最佳实践

n8n 本身提供了一些安全配置选项，很多人在初次部署时为了图方便都跳过了。

强制使用强密码：确保管理员和所有用户账户都使用复杂、唯一的密码。不要在多个地方重复使用密码。
启用并配置“外部钩子”：对于需要从公网接收触发信号的 Webhook，n8n 提供了“外部钩子”功能。启用后，Webhook URL 会包含一个长随机字符串，极大增加了攻击者猜测和访问的难度。在“设置”->“外部钩子”中启用。
审计与日志：开启 n8n 的详细日志，并确保日志被收集到集中的日志管理系统（如 ELK Stack, Graylog）。定期审计日志，关注异常登录、大量失败的身份验证尝试、来自异常 IP 的工作流创建或执行记录。
凭证管理：
- 尽可能使用 n8n 的“凭证”功能来存储密钥，而不是硬编码在工作流 JSON 中。
- 定期轮换 API 密钥和密码。
- 遵循最小权限原则，为不同的工作流或集成使用不同的、权限受限的凭证。
工作流审查：对于团队使用，建立工作流代码审查制度。特别是对包含“Function”或“Code”节点的工作流，要检查其代码是否安全，有无执行任意用户输入的风险。

4.4 高级防护：沙箱与运行时隔离

对于安全要求极高的环境，可以考虑更激进的隔离方案。

Docker 容器强化：运行 n8n 的容器使用非 root 用户。在 Dockerfile 或运行命令中指定-u参数。
```
docker run -d --user node ...
```
同时，考虑使用--read-only挂载根文件系统为只读，并仅将必要的目录（如/home/node/.n8n）以卷的形式挂载为可写。
使用安全沙箱：虽然 n8n 的代码节点在较新版本中尝试了沙箱隔离，但 JavaScript 的沙箱逃逸技术层出不穷。对于执行不可信代码的场景，最安全的方式是彻底禁用自定义代码节点。可以在环境变量中设置N8N_DISABLE_PRODUCTION_FEATURES或通过配置禁用相关节点。
独立部署：将 n8n 部署在一个独立的内网子网或命名空间中，严格限制其出站和入站网络连接，仅允许访问其必需的后端服务（如指定的数据库、API 端点）。

5. 漏洞事件后的应急响应与排查清单

如果你的 n8n 实例在修复前已经暴露在公网一段时间，仅仅升级是不够的，你需要假设自己可能已经被入侵，并进行排查。

5.1 入侵迹象排查

请立即检查以下项目：

检查用户和会话：
- 登录 n8n 管理界面，查看“用户”列表，是否有未知或新增的管理员账户。
- 检查 n8n 日志，搜索大量的POST /api/v1/workflows或PUT /api/v1/workflows请求，特别是来自异常 IP 的。
审计所有工作流：
- 逐个审查工作流，尤其是近期创建或修改的。重点检查“Function”、“Code”、“SSH”、“Execute Command”等节点。
- 查看工作流中是否包含可疑的 URL、IP 地址、加密的字符串或大段的混淆代码。
- 使用 n8n 的版本历史功能（如果开启），对比工作流的更改记录。
检查系统层面：
- 登录运行 n8n 的服务器，检查是否有未知的进程、计划任务、服务或用户账户。
- 使用命令如netstat -tunlp查看是否有未知的端口监听。
- 检查/tmp、/dev/shm等目录是否有可疑文件。
检查连接凭证：
- 假设所有存储在 n8n 中的凭证（数据库密码、API 密钥、云服务凭证）均已泄露。制定计划，对这些凭证进行批量轮换。

5.2 应急响应步骤

如果发现任何可疑迹象，请按以下步骤操作：

立即隔离：将受影响的 n8n 实例从网络中断开（关闭端口、停止容器/服务）。防止攻击者持续访问或数据外泄。
取证备份：在隔离后，对整个 n8n 的数据目录、Docker 容器镜像、系统日志进行完整的备份，以备后续法律或深度分析使用。注意：备份操作本身要小心，避免触发恶意代码。
搭建洁净环境：在一个全新的、安全的环境中，部署最新版本的 n8n。
恢复与重建：
- 谨慎选择：如果工作流未被篡改，可以导出旧实例中可信的工作流 JSON 文件，在新建的 n8n 实例中导入。导入前，必须用文本编辑器或代码检查工具仔细审核每一个工作流文件。
- 彻底重建：更安全但更耗时的方式是，根据业务文档，在新建的实例中手动重新创建所有关键工作流。所有凭证使用新生成的。
全面加固：按照本章第 4 节的内容，对新环境实施所有加固措施。
监控与告警：在新环境上线后，加强监控。设置对异常 API 调用频率、非工作时间的工作流执行、来自海外的登录尝试等行为的告警。

5.3 长期安全监控建议

安全是一个持续的过程，而非一次性的任务。

订阅安全公告：关注 n8n 官方 GitHub 仓库，开启“Watch”中的“Releases only”选项。加入相关的技术社区或安全邮件列表。
建立定期升级流程：制定策略，每隔一个固定周期（如每季度）评估并升级 n8n 到稳定版本。对于严重安全更新，应建立 24-48 小时内应急升级的流程。
自动化漏洞扫描：如果条件允许，可以使用软件成分分析工具，对包含 n8n 的整个应用栈进行定期的漏洞扫描。
进行渗透测试：定期邀请专业的安全团队或使用自动化工具，对暴露在外的 n8n 服务进行授权下的渗透测试，主动发现潜在问题。

这次 CVE-2026-21858 和 CVE-2025-68613 漏洞链事件，再次提醒我们，便利性与安全性往往需要权衡。像 n8n 这样功能强大的自动化工具，在成为生产力利器的同时，其复杂的代码和集成面也带来了可观的安全风险。作为使用者，我们不能抱有“部署完就高枕无忧”的心态。我的切身经验是，对于这类核心业务组件，必须将其纳入正式的安全运维体系：及时跟进版本更新、实施严格的网络访问控制、定期审计配置与日志、并对运行环境进行深度加固。把安全当作一个贯穿始终的特性来对待，而不是事后补救的选项，才能让我们在享受自动化带来的效率飞跃时，不至于让整个系统暴露在未知的风险之中。