上周二（8月19日），知乎同一天出现了两篇安全分析，一篇写n8n，一篇写Langflow。两个自托管Agent工作流编排里最容易用到的平台，同一周爆出问题。更有意思的是两者的差别：n8n漏的是"钥匙"——攻击者可以让你的服务器带着你配置好的凭证，去请求任意外部主机；Langflow漏的是"服务器"本身——不需要密码就能写文件、拿权限，cron、SSH公钥、webshell三条接管路径都成立。
一个漏钥匙串，一个直接敞开了房门。如果你家里的NAS或小服务器上正好跑着这两个东西，值得花10分钟做一次自查。
一、n8n：你的白名单，可能只是摆设
先说明：n8n这个漏洞，目前我只找到一篇中文信源，n8n官方安全公告渠道还没有后续，下面的判断基于这篇分析，建议以后续官方公告为准。
按这篇分析的说法，编号CVE-2026-56348，属于SSRF（CWE-918），影响2.20.0之前的版本。问题出在一个叫`POST /rest/dynamic-node-parameters/options`的接口上——这个接口是前端配置节点参数时，让服务器代为请求外部服务用的（比如拉取某个下拉框的选项列表）。n8n本来有个防御配置叫Allowed HTTP Request Domains，意思是"只允许请求我白名单里的域"，但这个接口没有强制执行这个限制。知乎
翻译成人话：攻击者只要能登录你的n8n（哪怕是个低权限账号），就能通过这个接口，让你的服务器带着你在n8n里配置好的凭证信息，去请求任意外部主机。你以为设了白名单，其实白名单被一个接口绕成了摆设。
有两个可以松口气的点：第一，这不是零点击漏洞，攻击者得先有一个认证账号，如果你的n8n密码够强、账号少，风险直接降一档；第二，修复方式明确，升级到2.20.0及以上即可。真正危险的是把版本号钉死在docker-compose里的人——很多人写的是`image: n8nio/n8n:1.x.x`，不主动改，就永远停在旧版本。
二、Langflow：补丁出了两个月，野外利用才开始
Langflow这个，多信源可以坐实。
CVE-2026-5027，CVSS官方评分8.8，GitHub的GHSA页面直接给到9.9。影响1.8.4及以下，漏洞是路径遍历导致的任意文件写入，默认部署下可以进一步拿到远程代码执行。修复进度上各信源口径不太一致：一篇详细复盘说4月15日发布的1.9.0版本已经修复，另一篇6月10日发布的分析则称当时官方补丁尚未发布。知乎不管信哪个，动作都一样：升级到官方最新版本。更要命的其实是Langflow的老问题：默认开启auto-login，等于实例天然处于零认证状态。公网测绘数据显示，暴露在外的Langflow实例大约有7000台，其中多少是这个状态，可以想见。知乎
攻击者的接管路径也被整理得很清楚：加cron定时任务、写SSH公钥、放webshell，三条路随便一条都能实现持久化。知乎
时间线值得单独拎出来看：补丁4月15日就发布了，野外利用6月9日才被确认，中间隔了将近两个月。知乎这不是坏事被拖延，而是漏洞利用的正常节奏——补丁发布后，攻击者从diff里反推出利用方式，再批量扫描没升级的主机。补丁之后的两个月，不是安全期，是最危险的窗口期。
为什么中招的总是AI编排平台？AI工具的使用者往往不是安全团队，而是算法工程师和数据科学家——他们可能根本不订阅CVE通知。知乎
三、偷走的钥匙到底能干什么？AI Agent替你用了
你可能觉得：我的实例在内网，漏洞归漏洞，轮不到我。那看一个7月的真实案例，再重新估计一下"钥匙串"的价值。
Sysdig团队披露了一起代号JADEPUFFER的勒索攻击：从入侵到加密的全过程，都由一个AI Agent驱动，没有任何人类黑客坐在键盘前指挥它。知乎知乎
入口是Langflow的一个严重漏洞CVE-2025-3248，CVSS评分9.8：它的代码验证接口不需要任何身份认证，任何人只要能访问到，就能在服务器上执行任意Python代码。知乎进入之后，Agent横向移动到内网的MinIO对象存储，又摸到生产环境的MySQL和Nacos配置中心，最终把1342条Nacos服务配置加密勒索。微博
这件事说明：编排平台里装的不只是工作流，还有你为了让工作流跑起来而插进去的所有钥匙——大模型API Key、数据库密码、第三方服务Token。攻击者要的从来不是你的画布，是这串钥匙。而且钥匙被偷之后的用法也在进化：不再靠人肉写脚本榨价值，而是让AI Agent自己探索怎么用。
四、一份10分钟自查清单
下面三步，按顺序执行即可。
第一步：查版本，先备份再升级。
n8n：确认版本≥2.20.0。如果你的docker-compose里钉死了旧版本号，备份好数据再改。
Langflow：确认版本≥1.9.0。1.8.x到1.9.0跨度不小，升级前先导出流程和配置。
如果暂时没法升级，至少先把公网暴露面收掉（见第二步），给自己争取时间。不确定自己是否受影响的话，对照修复版本号查一遍当前版本就知道了。知乎
第二步：查暴露面。
依次过四个问题：实例是否直接暴露在公网？是否还在用默认端口（n8n的5678、Langflow的7860）？Langflow的auto-login是否还开着？真的需要公网直达，还是VPN/内网穿透就够用？
自托管编排平台最稳的姿势，是"默认不暴露公网入口+反向代理加一层认证"，而不是把管理界面直接挂在公网上。
第三步：清点凭证，估算爆炸半径。
打开你的工作流列表，数一数接了哪些凭证，按权限从大到小排一遍：大模型API Key（尤其有余额的）、数据库读写密码、云服务AK/SK、第三方服务Token。权限大的、以及你都想不起来干什么用的，优先轮换。注意：轮换要去对应平台把旧密钥删掉，只新增不删除，等于换了一把锁但旧钥匙还能开门。凭证要假设随时可能泄露，轮换不是"出了事再说"，而是运行AI平台的基础运维动作。知乎
再补两条建议：给工作流里用到的账号最小权限，只读够用的就别给读写；保留执行日志，真出事的时候，日志是唯一能告诉你"哪个流程调用过什么"的东西。
五、用云托管的，可以松口气了吗？
基本可以。这次两个漏洞都是自托管部署的问题，云托管版本的补丁节奏和暴露面管理在厂商手里，你不需要自己动手。
但也不是高枕无忧。下一个坑已经露头：编排平台的攻击面正在从"输入→输出"扩展到"Agent→工具→数据库→其他Agent"，漏洞的爆炸半径会沿着多跳执行链几何级放大。知乎连租户之间的边界都不保险——已经出现只要知道别人的flow ID，就能触发执行对方工作流的IDOR漏洞。这已经不是单点漏洞问题，而是整个品类的结构性问题，值得持续关注。
写在最后
这两年，编排平台的角色悄悄变了：从"连接器"变成了"钥匙串"。这次两个漏洞，一个漏钥匙、一个漏房门，指向的是同一件事——你的编排平台上跑的不再只是自动化，而是一整套别人眼红的资产。
三件事今天就能做完：升级到修复版本、收掉暴露面、轮换高危密钥。后续值得盯三个信号：n8n官方公告是否确认CVE-2026-56348的细节、Langflow 1.9.x是否出现新CVE、这波漏洞有没有演变成真实的泄露事故。任何一个有动静，这份自查清单的优先级都值得再提一档。
