Langflow 是累積 155,921 顆星的視覺化 AI Agent 工作流平台，以拖拉節點建立 RAG 流程、多代理協作與工具呼叫，並可發布為 API 或 MCP 伺服器。星數背後有一組較少被討論的數字：過去十二個月發布 35 份安全公告，其中 16 份為嚴重等級、12 份高風險，與官方所稱的企業級安全存在落差。
Langflow 是什麼？
Langflow 是開源視覺化 AI 工作流平台，以節點畫布建立 RAG 與多代理流程，可輸出為 API 或 MCP 伺服器。專案以 Python 撰寫、MIT 授權，星標 15.5 萬。
專案由 Langflow 團隊於 2023 年 2 月建立，目前主要語言為 Python，授權條款為 MIT，累積 10,237 次分支與 376 位貢獻者。它的核心價值在於把「流程編排」這件事從程式碼搬到畫布上：使用者拉入模型節點、向量資料庫節點、工具節點，以連線定義資料流向，再透過互動式測試面板逐步檢視每個節點的輸入與輸出。
這個設計讓原型開發的速度大幅提升，也讓非工程背景的成員能參與流程設計。代價是所有節點都必須在同一個執行環境內具備實際能力，包括執行 Python 程式碼、發出網路請求、讀寫本機檔案與啟動子程序。當這些能力被包裝成可視化元件，安全邊界就不再由開發者逐行把關，而是由平台的權限模型決定。
Langflow 同時提供三種使用形態：本機安裝的 Python 套件、內含相依環境的桌面版，以及部署在伺服器上的多人協作執行個體。第三種形態正是多數安全公告的觸發場景，因為一旦執行個體暴露在網路之上，畫布上的每個節點都成為潛在的攻擊入口。
Langflow 這一年出了哪些安全公告？
過去十二個月共 35 份公告，16 份嚴重、12 份高風險。主要類型為遠端程式碼執行、權限繞過、路徑穿越與弱金鑰，修補版本集中於 1.9.0 至 1.12.7。
依照 GitHub 安全公告資料庫的紀錄，Langflow 自 2025 年 6 月起累計 37 份公告，其中 35 份落在最近十二個月之內。嚴重等級的 16 份公告中，有多份具備相同的技術輪廓：攻擊者只要取得一般使用者權限，就能透過平台內建的能力升級為作業系統層級的執行權。
其中最具代表性的三份，分別對應三種不同的失效模式。CVE-2026-105740 涉及 MCP 的標準輸入輸出通道，任何已驗證使用者都能藉由設定指令執行任意系統命令，修補版本為 1.9.0。CVE-2026-33017 則是公開流程建置端點的未授權遠端程式碼執行，屬於典型的暴露面配置問題。另一份編號 GHSA-jxw3-mjmx-3pqm 的公告更為隱蔽：金鑰產生流程誤用亂數種子，導致 Fernet 金鑰可被預測，連帶使加密保護形同虛設，修補版本為 1.10.1。
其餘公告涵蓋路徑穿越、跨專案檔案揭露、IDOR 越權存取、SSRF 與提示注入導致的程式碼執行。值得注意的是公告的時間分佈並不平均：2026 年 3 月與 6 月各有 8 份，2026 年 9 月則有 7 份。這種集中並非偶然，而是外部研究者在同一時期對同類平台展開系統性審查的結果。
為什麼一個視覺化 AI 平台會累積 16 個嚴重漏洞？
視覺化節點本身具備執行程式碼、發網路請求與讀寫檔案的能力，任何權限疏漏都會升級為系統層級風險。流程可分享與公開建置，暴露面遠大於一般應用。
根本原因在於能力與權限的耦合方式。一般 Web 應用若出現權限檢查疏漏，攻擊者取得的通常是資料；Langflow 若出現同類疏漏，攻擊者取得的是執行環境。當一個平台同時提供 Python 直譯節點、Shell 指令節點與檔案讀寫節點，任何一個節點的授權檢查失效，都等於把伺服器的命令列交出去。
第二個因素是流程的可分享性。Langflow 鼓勵使用者把流程發布成公開連結或公開建置端點，方便同儕試用；但公開與可執行一旦重疊，任何能觸及該網址的人就取得觸發整條流程的能力。官方後續的修補方向正好對應這一點：1.12.7 的多項修正集中在「限制非擁有者的圖譜覆寫」、「在公開元件建置上強制管理策略」與「拒絕執行期載入器與環境變數能力」。
第三個因素來自生態複雜度。Langflow 支援數十種模型供應商、向量資料庫與外部工具連接器，每個連接器都是一段需要自行處理 URL 驗證、憑證隔離與錯誤清理的程式碼。SSRF 公告特別指出，保護機制預設關閉且僅發出警告，且未涵蓋 RSS、SearXNG、網路搜尋、Home Assistant、Glean 與 Docling 等元件；這種「同一類風險分散在多個連接器」的結構，使修補難以一次到位。
這些漏洞對實際部署造成什麼風險？
風險等級取決於部署形態。桌面版與單人本機執行個體暴露面有限；一旦部署為多人協作的公開服務，嚴重漏洞可導致伺服器命令執行、跨專案資料讀取與雲端憑證外洩。
單人本機使用的情境風險最低。桌面版把相依環境一併封裝，服務預設只監聽本機位址，攻擊者必須先取得本機存取權，才有機會利用平台漏洞；在這種形態下，漏洞的實際影響大致等同於使用者自己的操作權限。
真正的風險集中在團隊部署。官方文件建議的入門方式是安裝 Python 套件後執行服務，預設監聽 127.0.0.1 的 7860 埠；但實務上為了讓同事或外部系統存取，往往會被放到反向代理之後並開放公網。此時公告中的 IDOR 與跨專案檔案揭露類問題，會讓同一個執行個體上的不同專案彼此可見；而遠端程式碼執行類問題，則可能被用來讀取環境變數中的模型 API 金鑰、資料庫密碼與雲端憑證。
另一個容易被忽略的面向是流程本身即為攻擊載體。提示注入類公告顯示，惡意內容可以誘導 Smart Transform 之類的節點產出可執行的程式碼；當流程處理來自網頁、郵件或使用者上傳文件的內容時，輸入面等同於網際網路。對把 Langflow 用作對外服務後端的團隊而言，這意味著必須同時考慮傳統 Web 攻擊與模型層的輸入操控。
Langflow 官方如何回應與修補？
官方以版本線分批修補，並為舊版回溯安全修正。1.12.7 的十五項修正有十項標記為安全性，1.12.5 亦有九項涉及權限收緊。
修補節奏呈現兩條並行的線。第一條是新版本的即時修正：1.12.5 於 2026 年 10 月 6 日發布，內容包括限制內建程式碼執行僅限管理員、把儲存的對話附件限制在授權範圍、強制 A2A 執行採用驗證策略，以及從管理回應中遮蔽伺服器憑證。這些都屬於權限模型層級的調整，而非單點修補。
第二條是針對既有版本線的回溯。1.12.6 的發布說明直接寫明包含「1.13.0 的安全性回溯」，1.12.7 則把範圍擴大到 OpenSearch 連接器 URL 驗證、S3 上傳範圍限制、拒絕程序與程式碼載入器能力、封鎖執行期物件還原、在獨立建置器中強制模型策略，以及把已儲存的流程與公開歷史識別碼分離。十五項修正中十項標記為安全性，比例之高說明當期重心確實放在收斂攻擊面。
官方同時在部署文件中加入明確提醒：正式發行版與標記版本的原始碼壓縮檔預設關閉自動登入，使用者必須先設定超級使用者密碼才能啟動。這項改動等於承認早期版本在預設配置上過於寬鬆，也把安全責任部分移轉給部署者。
自架 Langflow 的團隊應該做哪些防護？
先確認版本不低於 1.12.7，並在啟動前設定超級使用者密碼。把服務限制在內部網路或加上驗證層，停用非必要的程式碼與 Shell 節點，並定期檢視公告資料庫。
第一項是版本紀律。公告中所有嚴重問題都已在特定版本修補，把執行個體升到 1.12.7 或更新的版本，即可覆蓋已披露的攻擊路徑。若因相依套件衝突無法升級，至少應逐項核對自己使用到的節點類型，確認對應的修補是否已進入目前版本。
第二項是網路邊界。Langflow 的設計預期在受信任網路內運作，公開暴露時應在前面加上具備身分驗證的反向代理，並以白名單限制可存取的來源。文件中提到的伺服器金鑰與超級使用者密碼，都不應沿用預設值或範例值。
第三項是最小能力原則。Python 直譯節點、Shell 指令節點與檔案讀寫節點，只應開放給確實需要的人員；對外提供的流程應避免包含可直接執行任意程式碼的元件。官方在 1.12.5 之後已把內建程式碼執行限制為管理員專屬，這也說明能力分級是可行的收斂方向。
第四項是監控與更新習慣。Langflow 的公告密度意味著每季都可能出現新的修補版本；把 GitHub 安全公告加入訂閱、把版本更新納入例行維護，比事後追查入侵痕跡更符合成本。
Langflow 的數據表現如何？
星標 155,921、分支 10,237、貢獻者 376 位，採 MIT 授權。專案自 2023 年 2 月建立，2026 年 10 月仍每日提交，最新版 1.12.7。
星數與貢獻者規模說明專案的社群基礎穩固，376 位貢獻者的分布也解釋了為何程式碼審查需要依賴自動化與外部研究者回報。372 個貢獻者分頁對應的是一個高度分散的提交歷史，這類專案很難靠少數維護者逐行掌握每個連接器的安全假設。
提交活躍度同樣值得記錄。專案在 2026 年 10 月 22 日仍有新的推送，版本節奏約為每週一次修補版本、每月一次功能版本。這種節奏對安全有利，因為修補能較快落地；但也意味著部署者若長期凍結版本，就會逐步落後於公告。
出處連結有哪些？
完整原始碼、版本發布與安全公告均可在 GitHub 的 langflow-ai/langflow 儲存庫查閱，公告頁面另列 CVE 編號與修補版本。
專案位址為 https://github.com/langflow-ai/langflow，安全公告集中於儲存庫的 Security Advisories 頁面，每份公告均標示受影響版本範圍、修補版本與 CVE 編號。版本發布紀錄則可在 Releases 頁面逐項核對，最近的 1.12.5、1.12.6 與 1.12.7 都已公開完整變更清單。
總結：Langflow 還值得用嗎？
值得用，但必須當作具備執行能力的內部服務來對待。版本維持在 1.12.7 以上、關閉公開暴露、限制程式碼節點權限，即可在保留便利性的同時把風險壓回可接受範圍。
三十五份公告不必然代表專案品質低落，而是反映它所承擔的能力範圍。一個能執行 Python、發出網路請求、串接數十種外部服務的視覺化平台，本來就會吸引系統性的安全審查；真正需要檢視的是回應速度與修補覆蓋率，而 Langflow 在最近三個版本中把過半修正額度用於安全，說明維護方已把這件事放在優先位置。
對個人與小型團隊而言，桌面版或本機執行個體仍是低風險且高效的選擇。對把 Langflow 部署為內部服務的組織而言，關鍵動作是把預設配置當作不安全的起點：先設密碼、再限網路、然後關閉不必要的執行能力。把這三步做完，十五萬顆星所代表的生態價值才真正可用。
