Langflow 漏洞被利用：AI 工作流安全开始变重要

Langflow 最近披露了一个高危漏洞，而且已经有攻击者在野外利用。

这件事值得关注，不只是因为又一个开源工具出了漏洞。

更重要的是，Langflow 站在一个越来越敏感的位置：AI 工作流层。

很多团队用 Langflow 这类低代码平台搭 AI 应用和 Agent，把模型、文件、数据源、API、工具调用和自动化步骤串起来。

所以风险不再只是「AI 答错了」。

风险开始变成：AI 周围的工作流，已经进入了公司系统。

发生了什么

根据 Tenable 官方 advisory，Langflow 的 POST /api/v2/files 接口没有正确清理 multipart form data 里的 filename 参数。攻击者可以通过 ../ 这类路径穿越序列，把文件写到任意文件系统位置。

Tenable 给出的 CVSS 分数是 8.8，高危。修复建议是升级到 Langflow 1.9.0 或更高版本。

The Hacker News、BleepingComputer、SecurityWeek 等安全媒体也报道了这个漏洞被利用的情况，并引用了 VulnCheck 的观察。

从技术类别看，这是一个传统 Web 安全问题：文件上传、路径穿越、任意文件写入。

但它发生在 AI 工作流平台上，意义就不一样了。

因为影响不只取决于上传接口本身，还取决于这个平台能碰到什么。

为什么 AI 团队要重视

过去谈 AI 安全，很多人首先想到模型：幻觉、prompt injection、有害输出、拒答策略、训练数据泄露。

这些问题当然重要。

但当 AI 变成工作流，风险会往外扩散。

模型本身可能没出问题，工具链也可能先被打穿。

当一个 AI 工具可以读文件、写文件、调 API、连数据库、跑脚本、持有内部凭证时，它就不只是助手。

它已经进入执行层。

于是安全问题不再只是：AI 答案对不对？

还包括：

• 这个工作流能碰到哪些系统？
• 进程能读写哪些文件？
• 运行时能拿到哪些凭证？
• 服务是否暴露在公网？
• 每次动作有没有日志？
• 改动真实系统前，能不能停下来让人审核？

真正的教训：AI 工作流需要边界

Langflow 这次事件提醒团队：AI 工作流工具的价值来自连接。

但连接越多，攻击面也越大。

一个文件上传接口，如果背后的进程能写敏感目录、碰配置文件、或者带着过大的系统权限运行，它就不只是一个上传接口。真正的影响取决于部署方式：认证、网络暴露、文件权限、密钥、容器和运行时隔离。

所以，AI 工作流工具一旦接进公司系统，就不能再当成无害原型。

至少应该有这几条基本纪律：

1. 补丁和版本纪律
   及时更新 Langflow 和类似工具。针对 CVE-2026-5027，Tenable 建议升级到 Langflow 1.9.0 或更高版本。

2. 限制网络暴露
   除非有明确理由和强访问控制，不要把 workflow builder 暴露在公网。

3. 最小权限执行
   工作流进程不应该能读写超过任务所需的文件和目录。

4. 凭证隔离
   API key、数据库凭证、环境变量都应该按范围隔离，并能轮换。

5. 日志和审核点
   关键动作要可见、可审计，必要时能被人叫停。

对 Agent 产品意味着什么

AI 工作流安全不只是漏洞问题。

它是管理问题。

当 Agent 变得越来越能干，公司真正缺的未必是更多 Agent，而是管理 Agent 的方式。

客服 Agent 不应该顺手读到财务合同。内容自动化 Agent 不应该拿到生产数据库凭证。外部群聊机器人不应该和内部管理后台共享上下文。能打开浏览器、跑终端、改文件、调 API 的 Agent，每一步都应该留下可见记录。

这就是产品层的重要性。

Buda 更像一个 AI Agent Workspace，而不只是聊天框。Agent 可以在隔离沙箱里工作，用 Drive 作为显式知识来源，在 Session 里留下工具调用和文件变化，并让人类保留审核和批准的位置。

目标不是让 Agent 变弱。

目标是让它们的执行变得可见、有边界、可管理。

AI 工作流不是玩具。跑起来只是第一步。能安全地跑在真实公司里，才是更难的一步。

在 Buda dashboard 探索 Agent 工作台。