文章总结： n8n修复高危表达式沙箱逃逸漏洞(CVSS8.7),攻击者需有效账号且能编辑工作流,成功后以n8n进程权限执行命令。官方修复版本2.31.5和2.32.1。文章强调工作流编辑权限应视为高风险,提出四条处理建议:确认真实版本、重算编辑权限、检查主机与工作流证据、决定是否轮换凭据,并建议补上进程、凭据和变更三道边界。 综合评分： 88 文章分类： 漏洞分析,安全建设,安全运营,web安全

n8n 修了一个沙箱逃逸：为什么“能编辑工作流”已经接近服务器权限

原创

tcode tcode

字节脉搏实验室

2026年7月28日 10:17 北京

在小说阅读器读本章

去阅读

    7 月 27 日，The Hacker News 报道 n8n 已修复一项高危表达式沙箱逃逸。n8n 官方安全公告编号为 GHSA-gv7g-jm28-cr3m，CVSS 4.0 评分 8.7。攻击前提不是匿名访问，而是攻击者已经拥有有效账号，并被允许创建或修改工作流；成功后，系统命令会以 n8n 进程的权限运行，不需要另一名用户配合操作。

    官方列出的修复版本是 2.31.5 和 2.32.1。管理员应升级到对应维护分支的修复版本或更高受支持版本。官方临时建议是只允许完全可信的用户访问实例并编辑工作流，但同时明确，这些措施不能完整消除风险，只适合作为短期缓解。

    一名工作流编辑者，究竟能碰到多少东西

    把这个问题只理解为“能在服务器上运行一条命令”，反而会低估它。n8n 的价值来自连接：邮件、数据库、CRM、云服务、Webhook、内部 API 和凭据仓库都可能通过同一个平台串联。n8n 进程本身的操作系统权限也许有限，但它保存的密钥和能够到达的服务，可能比系统账户权限更重要。

    研究方 Security Joes 指出，若攻击者进入进程上下文，可能接触 n8n 的加密密钥，并进一步威胁平台保存的连接凭据。实际影响取决于部署：容器是否只读、密钥是否外置、服务账户权限多大、主机能否访问生产网络、同一实例是否承载多个部门的自动化。

    所以，风险评估不能停在“n8n 不是以 root 运行”。正确问题是：这个进程能够读取哪些秘密、调用哪些接口、写入哪些业务数据，以及它所在的网络区域允许它向哪里发起连接。

    这不是一次孤立的补丁问题

    表达式沙箱的目标，是让用户能处理数据，又不能触碰真实 Node.js 运行时。此次问题来自表达式重写与属性检查的组合缺口。本文不复述绕过方式，但它说明一个长期事实：任何允许用户编写接近代码的表达式系统，都需要按代码执行边界管理，而不能只靠界面上“低代码”三个字降低风险等级。

    Security Joes 是在复查今年早些时候另一个 n8n 沙箱问题的修补效果时发现该缺口。公开资料显示，研究方在报告形成时没有观察到在野利用；官方公告也没有声称漏洞已被利用。没有利用证据意味着不能把所有旧版本实例都写成已失陷，但不意味着可以把升级排到普通功能发布之后。

    企业今天应该分四条线处理

    第一条线：确认真实版本。检查所有自建实例、容器镜像、灾备副本和临时环境，不能只看编排文件中的目标标签。记录应用实际返回的版本、镜像摘要和实例所有者，升级到 2.31.5、2.32.1 或更高受支持版本。

    第二条线：重算编辑权限。列出谁能创建、导入、修改和执行工作流，包括外包、测试账号、机器人账号和跨部门共享账号。对没有持续业务需要的权限立即回收；开放注册、弱口令和长期不审计的共享账号应优先处置。

    权限盘点还要区分查看、手动执行、编辑表达式、导入流程和管理凭据。仅需观察运行结果的业务人员不应保留编辑能力；只能维护单一流程的团队，也不应默认访问其他部门的连接。把“工作流编辑者”从宽泛角色拆成具体动作，才能减少一个账号接管后的横向影响。

    第三条线：检查主机与工作流证据。关注近期新建或异常修改的工作流、难以解释的表达式、异常执行时间，以及 n8n 或 Node.js 进程产生的命令解释器、下载工具和未知子进程。调查应先保存工作流版本与执行日志，再进行清理，避免覆盖时间线。

    第四条线：决定是否轮换凭据。如果只发现旧版本但没有可疑活动，不必无差别轮换所有业务密钥；先升级并提高监控。如果发现异常工作流、主机命令或敏感文件访问，应在隔离实例后，按连接清单轮换数据库、云平台、Webhook、OAuth 和内部 API 凭据。先轮换、后隔离，可能让新凭据再次暴露。

    平台设计要补上三道边界

    第一道是进程边界。使用非特权账户、只读文件系统、最小挂载目录和受限出站网络，不让自动化平台默认看到整个主机与生产网段。

    第二道是凭据边界。不同业务域使用不同凭据和实例，服务账户只授予工作流必要的动作；能够读取客户数据的连接，不应同时拥有管理基础设施的权限。

    第三道是变更边界。敏感工作流采用审批、版本留存和双人复核，把表达式、代码节点与新连接视为代码变更。编辑者不一定是恶意人员，但账号一旦被接管，平台需要阻止一次编辑直接变成跨系统控制。

    信息边界

    已确认：官方公告将问题评为 High，修复版本为 2.31.5 与 2.32.1，利用需要具备工作流创建或修改权限的认证用户，成功后以 n8n 进程权限执行命令。7 月 27 日公开报道时没有已知 CVE，公开材料也没有确认在野利用。

    本文判断：自动化平台的工作流编辑权应归入高风险技术权限，而不是普通 SaaS 内容编辑权限。

    结语

    低代码没有消除代码执行，只是把代码藏进表达式、连接器和流程图。n8n 这次修复的直接任务是升级版本，更重要的管理动作，是重新回答“谁能修改自动化，以及一次修改最多能影响多少系统”。

    当工作流连接着企业最有价值的凭据和数据时，编辑器就是发布入口，平台就是执行环境。按这个标准设计权限、网络和审计，下一次沙箱问题才不会再次变成全域风险。

参考来源

• n8n 官方安全公告：GHSA-gv7g-jm28-cr3m（2026-07-22，GitHub 页面未显示具体时区）

• The Hacker News：n8n Sandbox Escape Lets Workflow Editors Run OS Commands（2026-07-27 18:35:15 +05:30；北京时间 21:05:15）

• Security Joes：Breaking the Sandbox Again（研究方原文；页面访问可能受地区策略限制）

免责声明：

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

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

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

本文转载自：字节脉搏实验室 tcode tcode《n8n 修了一个沙箱逃逸：为什么“能编辑工作流”已经接近服务器权限》