FreeBuf.COM网络安全行业门户，每日发布专业的安全资讯、技术剖析。

研究人员披露了n8n平台中一个已静默修复的关键漏洞细节，该平台被众多企业用于构建LLM驱动的Agent和自动化工作流。该漏洞可使未认证攻击者完全接管本地n8n部署，在底层系统执行命令，并提取工作流通常有权访问的敏感企业数据。

"受感染的n8n影响范围极其广泛，"发现该漏洞的数据安全公司Cyera研究人员在报告中指出，"n8n连接着无数系统——企业Google Drive、OpenAI API密钥、Salesforce数据、IAM系统、支付处理器、客户数据库、CI/CD管道等。它是自动化基础设施的中枢神经系统。"

n8n开发者已在11月18日发布的1.121.0版本中修复此问题，但当时的发布说明未提及安全补丁。这似乎是标准操作流程，因为n8n安全公告会刻意延迟发布。该项目此后还修复了其他关键RCE漏洞（CVE-2025-68613、CVE-2025-68668和CVE-2026-21877），用户应确保始终更新至最新版本。

内容类型混淆导致任意文件读取

该漏洞编号为CVE-2026-21858，严重性评分为10.0（高危），支持两阶段攻击。首先，它允许访问n8n网页表单的未认证攻击者从n8n服务器泄露内部文件。这是因为n8n表单节点用于接收数据的formWebhook函数未验证用户提交的POST请求中Content-Type字段是否设置为multipart/form-data。

设想一个常见场景：n8n被用于构建允许用户上传文件的聊天界面，例如接收错误截图的技术支持门户、提交简历的HR系统，或是员工上传文档供LLM驱动聊天机器人后续查询的知识库。

正常情况下，当内容类型为multipart/form-data且请求体包含files:定义时，n8n会通过parseFormData()函数解析请求，该函数使用Node.js库Formidable安全处理文件上传——将文件存储于随机路径的临时目录，再将文件名和位置填入req.body.files全局变量。

但如果请求采用不同内容类型（如application/json），n8n会调用行为迥异的parseBody()函数。该函数提取请求的data段填充req.body.data，同时提取其他所有段内容填充对应的req.body.[段名]变量。

由于formWebhook未验证含files段的请求是否确为multipart/form-data，将错误调用解析函数，导致req.body.files变量被用户控制的文件名和路径填充。随后调用的copyBinaryFile()函数会将req.body.files变量中的文件（本应是随机临时路径）复制至持久存储位置供其他节点/工作流使用，从而可能引发路径穿越攻击——覆盖系统合法文件或在工作流其他环节加载。

攻击者可提交application/json类型的请求，在files段指定本地系统已知文件路径（包括含敏感凭据的n8n配置文件）。若这些文件被加入LLM驱动聊天机器人节点的上下文，攻击者就能通过聊天界面查询文件内容实现泄露。

从任意文件读取到管理员权限

该漏洞支持的第二阶段攻击极大扩展了"影响范围"，因为任意文件读取能力结合n8n的会话认证机制将产生严重后果。

会话cookie是存储在用户浏览器中的字符串，用于维持一段时间的认证状态。攻击者常从受感染系统窃取会话cookie以绕过认证，在各种网站冒充受害者登录。

在n8n中，会话cookie通过组合用户唯一ID与邮箱密码的SHA256哈希值，再用安装专属密钥签名生成。问题在于重建会话cookie所需信息均存储于本地文件：唯一密钥位于/home/node/.n8n/config，所有用户记录存放于/home/node/.n8n/database.sqlite。泄露这两个文件内容可使攻击者为任意用户（包括管理员）重建n8n-authcookie。

获得管理员权限后，攻击者可创建新工作流。n8n提供的"执行命令"节点能如其字面意思——以n8n服务权限在底层操作系统执行命令。

"设想拥有万名员工的大型企业使用单一n8n服务器，"研究人员在报告中写道，"受感染的n8n实例不仅意味着丢失一个系统，更是将一切密钥拱手相让。API凭证、OAuth令牌、数据库连接、云存储——所有资源集中一处。n8n成为单点故障和威胁参与者的金矿。"

参考来源：

Critical RCE flaw allows full takeover of n8n AI workflow platform

本文为 独立观点，未经授权禁止转载。
如需授权、对文章有疑问或需删除稿件，请联系 FreeBuf 客服小蜜蜂（微信：freebee1024）