别只盯大模型了，漏洞都在工作流里

一个用来搭 AI 智能体的可视化平台，一次公告要修 25 个漏洞，其中两个是无需任何身份验证就能远程执行代码的严重漏洞。IBM 为 Langflow OSS 发布安全公告，给出的唯一建议是升级到 1.12.3——没有缓解措施，没有绕过方案。

几乎同一时间，Talos 发布了 CAIRN，一个专门用于狩猎、分类和追踪“AI 集成型恶意软件”的研究工具包。

两件事看似不搭界，其实指向同一个判断：AI 安全的战场，正在从模型层下沉到工作流层。你花重金守住的模型权重，可能败给一个没人打的补丁。

🚨 一份公告塞进 25 个漏洞，说明什么

在 Agent 平台上，代码执行不是漏洞，是产品形态。

先补一个背景：Langflow 是一个可视化环境，用来构建 AI Agent 和工作流，支持用 Python 做深度定制。这类工具的定位很像 AI 时代的低代码平台——拖拖拽拽就能把大模型、检索、数据库和外部工具串成一条业务流程。

按 IBM 的公告，这批漏洞影响 Langflow 从 1.0.0 到 1.12.2 的所有版本。也就是说，从项目走向正式版开始，安全风险就一路伴行到了今天。官方修复版本是 1.12.3，而且公告明确没有列出任何变通方案——想不升级硬扛，没有门。

25 个漏洞一次性打包披露，通常不是巧合。业内做漏洞运营的人大多能读出背后的信号：这更像是协调式的系统性审计，而不是零敲碎打的补丁作业。多位安全研究员在私下交流里的共识是——当一个项目要在一次公告里吞下两位数的漏洞，说明它的攻击面早就超出了维护团队此前的想象。

值得注意的是，这也不是 Langflow 第一次出现在攻击者的弹药库里。此前它就曾因代码执行类漏洞，在补丁发布后短时间内被僵尸网络批量武器化——对暴露在公网的实例“扫一遍、打一遍”，是现成的自动化生意。

🔓 未授权 RCE 加 Python 定制，是教科书级组合

真正值得紧张的，是那两个“未授权 RCE”。

拆开看这个组合有多危险：Langflow 的核心能力之一，就是让用户在流程里嵌入自定义 Python 组件。换句话说，这个平台生来就是要执行用户提交的代码的。一旦认证环节被绕过，原本的产品特性就变成了攻击者的入口——这几乎是 Agent 类平台的宿命级矛盾。

再算爆炸半径。这类工作流平台在真实企业里挂的是什么？大模型的 API 密钥、向量数据库的连接串、内部知识库的读取权限，以及一张通往内网的路由表。拿下一台 Langflow 实例，攻击者得到的往往不只是一台服务器，而是一整套“带钥匙的跳板”——通往模型供应商的账单、企业敏感数据和内网横向移动的起点。

更现实的问题是部署习惯。AI 项目的节奏催生了大量“先跑起来再说”的实例：docker 一拉、端口一开，demo 直接变成生产系统。红队圈子里这早已不是新鲜目标——只要按指纹扫一遍端口，收获往往超出预期。在安全研究员的私下交流里，一个反复出现的判断是：企业实际暴露的 AI 组件数量，普遍是资产台账上数字的好几倍。

🕸️ AI 开源供应链，责任正在悄悄上移

补丁晚一天，风险就多一天没有天花板。

这起事件真正的产业意味，在于“谁在出公告”。Langflow 是开源项目，但这次的安全公告由 IBM 发布。当一个开源 AI 工具被大厂纳入体系、进入企业采购视野之后，游戏的规则就变了：用户默认背书方会打补丁、会负责任地披露，而维护方也必须按企业级标准响应漏洞。

但现实是骨感的。1.0.0 到 1.12.2 全线受影响，说明这类高速迭代的开源 AI 项目，功能的进化速度远远跑在安全工程前面。这是整个赛道的通病，不只是某一个项目的问题。

对企业的启示很直接：当你把开源 Agent 框架焊进生产系统时，实际上是在做一次无合同的供应链外包。过去的教训已经写得很清楚——Log4j 时刻之所以惨烈，就是因为没人知道自己用了多少层开源依赖。AI 时代这一层只会更深：框架、运行时、模型服务、自定义组件，每一层都在引用别人的代码。

所以越来越多的做法是把硬指标写进采购流程：要求提供 SBOM、要求明确漏洞响应 SLA、要求关键组件有可追溯的维护主体。开源可以免费，风险从来不是。

🧬 CAIRN：防守方开始给 AI 化恶意软件建档案

攻击者在用 AI 提效，防守方不能只用嘴回应。

Talos 这次放出的 CAIRN，定位是对抗“AI 集成型恶意软件”的研究工具包，覆盖三个环节：狩猎（hunting）、分类（classifying）、追踪（tracking）。翻译成产业语言就是：面对一批开始把 AI 能力接进自身流程的恶意软件，防守方不再满足于单点样本检测，而是要系统性地识别、归族、持续盯梢这条“前沿线”。

这个动作和 Langflow 事件其实是一体两面。一边，AI 工具链在防守者自己的环境里制造了新的攻击面；另一边，AI 也在帮攻击者降低成本——批量写代码、快速变种、自动化侦察。攻防两端被 AI 同时挤压，谁能先把自己的“AI 化工具链”建起来，谁就握有身位优势。

落到企业侧，事件驱动的动作清单其实很短：

• 🔍 资产盘点：先搞清楚公司里到底跑着多少个 Langflow（或同类 Agent 平台）实例，公网暴露的全部收敛；
• ⬆️ 立即升级到 1.12.3：官方明确无缓解措施，升级是唯一解；
• 🔑 密钥轮换：所有挂在该平台上的 API 密钥、数据库凭据，按“已被读取”处理；
• 📡 行为监控：对平台内 Python 执行行为建立基线告警，RCE 的前置信号往往比漏洞通告来得早。

小结

大模型的参数从来不是企业最脆弱的一环，工作流才是。一次 25 个漏洞的补丁公告、一个专门追踪 AI 恶意软件的工具包，共同标定了 AI 安全的下一个主战场：开源工作流层。可以预判的是，Agent 平台的漏洞披露会常态化，攻击者对 AI 的集成也会从“用 AI 写代码”走向“在恶意软件里调 AI 接口”。防守方的弹药库，必须比攻击者的武器库跑得更快——否则你守住的模型，只是在替别人看门。