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 工作台。