如果你们的服务器或 NAS 上正跑着 n8n，建议先停下手头的事，花5分钟看完这篇。
8月18日到19日这两天，自动化工作流圈连着发生了三件事：n8n 被披露了一个凭证外泄漏洞（CVE-2026-56348）、最新版本 2.35.3 被实测出一个表达式回归、同一天另一个工作流平台 Langflow 的 RCE 漏洞也被完整复盘（CVE-2026-5027）。再叠加这个夏天不断涌入的自建新用户，现在恰好是"玩工作流"该冷静打地基的时候。
一件一件说。
一、凭证外泄漏洞：最吓人的不是漏洞，是"你以为设防了"
先说结论：n8n 版本低于 2.20.0 的，这一段跟你有关。
按照知乎8月19日发布的一篇技术文章的描述，CVE-2026-56348 是一个 SSRF 加域名白名单绕过漏洞：2.20.0 之前，n8n 的 POST /rest/dynamic-node-parameters/options 端点没有强制执行"Allowed HTTP Request Domains"域名白名单，拥有凭证访问权限的认证用户，可以让 n8n 服务器带着你的 API token、OAuth 密钥、数据库密码，向任意外部主机发起 HTTP 请求。知乎 翻译成人话：你存在 n8n 里的那些密钥，可能被服务器自己"合法地"带出门。
这里要说清楚证据边界：这个 CVE 目前只有社区单篇技术文章披露，官方安全公告和更多独立信源还没跟上，只能算"社区已披露、宁可信其有"。但它值得认真对待，原因有一个：
n8n 不是没有白名单功能。不少讲究的人早就在后台配过"Allowed HTTP Request Domains"，以为出站请求都受控了——偏偏这个端点漏了校验。你配的是配置，不是代码强制。配置总会漏，代码强制才是兜底。这个教训不只适用于 n8n，适用于所有自建平台。
再往深一层，是更根本的问题：n8n 的凭证库是集中存放的，LLM 的 API key、邮箱 SMTP、数据库密码，几十个服务的钥匙放在一个篮子里，篮子一漏就是全损。Langflow 那件事可以当镜子照：分析文章援引 Censys 的数据，公网上约有 7000 台默认配置下暴露的 Langflow 实例。知乎 而那个 RCE 的补丁 4 月中旬就发布了，6 月上旬才被确认在野利用——中间这将近两个月，就是"部署完就不管"的人交的学费。
二、升级翻车现场：2.35.3 的 sort() 会返回 null
如果说漏洞回答的是"要不要升级"，第二件事回答的就是"升级会不会也翻车"。
8月19日有技术作者做了隔离对照实验：从 2.34.5 升级到 2.35.3 之后，Edit Fields 节点里，直接对数组做原地变异的 sort()、splice()、fill()、copyWithin() 全部返回 null，而 reverse() 不受影响，先把数组复制一份再操作也完全正常。上游 n8n-io/n8n 的 Issue #36540 在 8月18日 已经报告了同样的现象。知乎 所以如果你刚升级完，发现工作流输出突然变成 null，先别急着怀疑输入 JSON 或者自己的表达式写法。最短修复就一句话：把数组复制一份再操作，比如 arr.sort() 写成 […arr].sort()，先让流程恢复，不必为了一个表达式回归把整条流改成 Code 节点。
三、为什么这周信息密度这么大
两个背景事实。
第一，自建的新人浪潮不小。B站 8月22日、23日连着上新了两套 n8n 零基础教程，知乎 8月24日 有入门指南，微博上 8月24日 深夜还有人在晒"N8N地端搭建成功"，知乎上甚至有人在问"docker 部署之后怎么拉取 n8n"——典型的"会部署、不会维护"。很多新人照着教程 docker run 一把跑起来就完事，版本号、白名单、暴露面，一概没碰过。
第二，企业已经进场。8月12日有行业媒体报道，奔驰将全员铺开 n8n 低代码 AI，把员工分成"使用者、创造者、构建者"三层，还发动了超过 1500 人的黑客松。微博 n8n 的 GitHub Stars 也已经站上了 20 万量级。知乎 工具热度猛涨的时候，运维素养通常是最后跟上来的，而安全事件就喜欢挑这个时间点敲门。
四、别急着 docker pull，分三种情况
我的建议是看自己的版本号，分三个分支走：
低于 2.20.0（装了很久没动过的重灾区）：升级。升完记得多做一步：把存在 n8n 里的重要凭证轮换一遍——漏洞若属实，换密钥才是唯一的了断。
已经在 2.35.x，且工作流里大量用了 Edit Fields 的排序、数组操作：先看输出里有没有异常的 null，有就先改成"先复制再操作"的写法，等上游修复，不必回退版本。
2.20.0 到 2.34.x 之间：没有紧迫的安全压力，可以等一个更稳的版本，但先把所有工作流的 JSON 导出一份存好。
不管在哪个分支，这 5 项自查都值得做一遍，加起来不超过 10 分钟：
查版本：后台左下角的版本号，或 Docker 里用的镜像 tag，确认自己在上面哪一档；
查暴露面：n8n 的管理端口能不能从公网直接打开、有没有设认证——这一条比任何 CVE 都致命；
查凭证：凭证库里存了多少把钥匙，不用的删掉，别留着过年；
查白名单：如果配过出站请求限制，验证一下它真的生效——这次漏洞恰好就是"看起来配了"的那种；
查备份：把工作流 JSON 导出来，或者直接备份数据库文件，几分钟的事，这是升级前的底气。
五、接下来值得盯的三个信号
n8n 官方渠道是否确认 CVE-2026-56348、发布安全公告，以及受影响版本范围有没有修订；
Issue #36540 是否有修复合入，并给出明确的"受影响版本→修复版本"对照；
工作流自动化平台整体的安全动向——Langflow 在 2026 年已经不止一次高危记录，这个赛道不会只响这一次。
自建就像自己租房住：自由是真自由，但水电安检没人送上门。这篇就算一张安检表。你们的 n8n 跑在哪个版本上？评论区聊聊，帮你看该走哪个分支。
