7,000 台 Langflow 主機遭攻擊：揭開 LangChain／LangGraph 編排層的同一種洞

瀏覽次數: 2

2026 年 3 月 17 日，Langflow 釋出了一份安全公告。大約 20 小時後，第一批針對它的攻擊流量就出現在蜜罐上——這是 Sysdig 威脅研究團隊（Sysdig TRT）記錄到的時間差。攻擊者不需要帳號、不需要密碼，只要對一個公開端點送一段 JSON，就能在受害容器裡執行任意指令，接著一行 env 把整個行程的環境變數倒出來：資料庫連線字串、API key、還有一把還在生效的 AWS access key。

這不是孤立事件。同一段時間，LangChain 與 LangGraph——也就是 Langflow 底下那一整層 AI 編排框架——被揭露了一連串性質高度相似的漏洞。把它們攤開來看，你會發現這不是「三個各自獨立的 bug」，而是同一種設計假設在不同套件裡反覆出現。對任何正在把 LLM agent 推上生產環境的團隊來說，這篇值得花十分鐘讀完。

本文大綱

先講清楚：這幾個東西是什麼關係

Langflow 是一個視覺化的 agent / workflow 編排工具，你可以拖拉節點把 LLM、工具、資料來源串成一條 flow，常被團隊拿來做 PoC 和內部工具，且多半是「自架」（self-hosted）。LangChain 是底層最廣為使用的 LLM 應用框架，官方數據量級在每週數千萬次下載；LangGraph 則是 LangChain 團隊推出、用來描述有狀態、有循環的 agent 圖（graph），它的 checkpoint 機制負責把 agent 的對話與狀態持久化到 SQLite、Redis 等後端。

這三者疊在一起，構成了現在很多人口中的「AI 編排層」（orchestration layer）。它的問題在於：這一層長期被當成「可信任的內部程式碼」來設計，但實際部署時，它往往直接坐在網路邊緣，接收使用者、甚至 LLM 自己生成的輸入。 信任邊界畫錯了地方，後面所有的洞都是這個前提的必然結果。

運作原理：一個未授權端點，如何拿下整台主機

先看這次風暴的中心——Langflow 的 CVE-2026-33017。

關鍵端點是 POST /api/v1/build_public_tmp/{flow_id}/flow。從名字就看得出來，它的用途是「讓未登入的人也能建置公開流程」。問題是，這個端點刻意繞過了認證——它不像受保護的 build 端點那樣要求 current_user。任何能連到這台 Langflow 的人，都能呼叫它。

接著是真正致命的部分。Langflow 的「自訂元件」允許在 flow 定義裡夾帶一段 Python 程式碼。後端處理流程大致是：把這段程式碼從參數裡取出（code = custom_params.pop('code')），丟給 ast.parse() 解析成抽象語法樹，編譯，然後在 prepare_global_scope() 裡用 exec() 執行。整條鏈路裡沒有 sandbox、沒有 ast.literal_eval、沒有子行程隔離，就是赤裸裸地把攻擊者的輸入餵給 exec()。

更陰險的一點，是執行時機。prepare_global_scope() 會去執行語法樹裡的 ast.Assign（賦值）節點。換句話說，像 _x = os.system("id") 這種「賦值」，在 Langflow 還只是組裝這張圖的時候就已經跑起來了，根本不必等到流程真的被觸發執行。研究者（JFrog 的 Aviv Engelberg 與 Ofri Ouzan）在實測中觀察到的攻擊 payload 正是這個形態：_r = __import__('os').popen('id').read()，把指令輸出做 base64 編碼後送往外帶（out-of-band）回呼伺服器。

到這一步，攻擊者已經能在容器內任意執行指令。Sysdig 觀測到的真實攻擊鏈很「教科書」：列目錄、讀 /etc/passwd 與 .env、用 id 做指紋辨識，然後一行 env 把環境變數整包倒出來。在典型的 Langflow 部署裡，這包環境變數通常就含有資料庫連線字串、各種 API key，以及雲端憑證——於是一把 live AWS access key 就這樣外洩，後續被拿去做雲端帳號偵察與濫用。從一個「不用登入的公開端點」，到一把生產環境的雲端金鑰，中間只隔了幾個 HTTP 請求。

不是一個洞，是同一種洞

如果故事只停在 Langflow，那它充其量是「又一個 RCE」。真正值得寫成長文的，是當你把鏡頭拉遠，會看到同一類設計缺陷散落在整個 LangChain 生態裡。

由資安研究團隊 Cyata / Cyera（以「LangDrained」之名揭露）整理出的這一批 CVE，可以歸成三類根因：

第一類：把不可信輸入交給 exec / eval。 這就是 Langflow 兩個 RCE（CVE-2026-33017 與更早、已列入 CISA KEV 的 CVE-2025-3248）的本質。在 LangChain 這邊，同樣的味道出現在 langchain-experimental 一系列「讓 LLM 生成程式碼再直接執行」的元件上——LLM 的輸出本身就該被視為不可信輸入，卻被當成可以直接 exec() 的程式碼。

第二類：不安全的反序列化。 LangGraph 的 checkpoint 把 agent 狀態存下來再讀回，問題出在讀回的方式。CVE-2025-64439 的核心是 JsonPlusSerializer 會根據資料裡的 id 欄位動態 import 並執行 Python 類別——也就是說，只要攻擊者能污染 checkpoint 內容，反序列化的當下就等於程式碼執行。另一個相關的 CVE-2026-28277 則是 checkpoint 載入時的 msgpack 不安全反序列化。LangChain core 本身也有一個被命名為「LangGrinch」的序列化注入（CVE-2025-68664，CVSS 9.3），能在受信任的命名空間裡實例化任意類別，並藉此把 prompt injection 升級成程式碼執行。

第三類：經典注入與路徑穿越。 CVE-2025-67644 是 LangGraph SQLite checkpoint 後端的 SQL 注入——metadata 過濾的鍵（filter key）沒有被妥善參數化，攻擊者能塞進任意 SQL。CVE-2026-34070 則是 LangChain core 載入 prompt 設定檔時的路徑穿越，可讀取主機上的任意檔案。研究者也指出，這些洞還能被串起來：在自架、且使用 SQLite 或 Redis checkpointer 並接受使用者可控過濾條件的部署裡，SQL 注入加上不安全反序列化，可以鏈成完整的 RCE。

把三類放在一起看，共同的故事是：編排框架預設「進到我這層的東西都是開發者自己寫的、可信任的」，於是省掉了沙箱、參數化、輸入驗證。 但 agent 的本質，恰恰是讓外部輸入（使用者訊息、檢索內容、工具回傳、甚至 LLM 自己的生成）能流動到執行路徑上。這個矛盾不修掉，補完一個 CVE 還會冒出下一個。

數據與限制：哪些數字可信，哪些要打折

寫安全新聞最容易出錯的地方就是數字，這裡逐一標註來源與前提：

「20 小時」 指的是 CVE-2026-33017 從公告發布到 Sysdig 蜜罐觀測到第一次野外利用的間隔，攻擊源為 6 個不重複 IP，其中 4 個是用 nuclei + interactsh 的自動化掃描，2 個是手寫的偵察與憑證竊取腳本。這是單一研究團隊的蜜罐觀測，反映「被自動化武器化的速度」，不是「全網受害數」。
「約 7,000 台暴露主機、多數在北美」 來自報導方對公網掃描的整理（VentureBeat 的標題數字）。需要對照的是，2025 年 CVE-2025-3248 揭露時，公開資料引用的 Shodan 數字約是 1,050 台。兩個數字時間點與口徑不同，請當成「同一量級、持續成長」來理解，而非精確普查。
CVSS 分數有分歧。 CVE-2026-33017 在不同來源被標為 9.8（CVSS 3.1 口徑）或 9.3（CVSS 4.0 向量）。兩者都屬 Critical，差異來自評分版本，不必糾結哪個「對」。
「修了等於沒修」的插曲值得記住。 JFrog 研究指出，一度被廣泛宣稱已修復 CVE-2026-33017 的 Langflow 1.8.2 版，實測仍可被同一個公開 PoC 在 PyPI 與 Docker 環境成功利用；真正堵住的是 1.9.0（與 langflow-base 0.9.0）。「升到最新版」不等於「升到有修的版本」——請以官方 advisory 指定的修補版本為準。
CISA KEV 狀態有時間差。 CVE-2025-3248 已於 2025 年 5 月列入 CISA 已知遭利用漏洞目錄；CVE-2026-33017 的部分報導稱其也已列入，但 Sysdig 撰文當下指出「確認遭利用、但尚未列入 KEV」。這類狀態會隨時間更新，採信前請直接查 CISA 官方目錄。
LangChain / LangGraph 的修補版本（請以官方為準）：langchain-core ≥ 0.3.81 / ≥ 1.2.22、langchain ≥ 1.2.5、langgraph-checkpoint ≥ 3.0、langgraph-checkpoint-sqlite ≥ 3.0.1、langgraph-checkpoint-redis ≥ 1.0.2、langgraph ≥ 1.0.10。另外一個重要前提：LangChain 的託管平台（LangSmith Deployment）不受這批洞影響，受影響的是自架部署。

該怎麼判斷：什麼時候你真的有風險

不是每個用 LangChain 的團隊都該驚慌。把 trade-off 講清楚：

高風險，立刻處理： 你自架了 Langflow，且它能被內網以外（甚至公網）連到——尤其是那個公開 build 端點。這幾乎是「現在就會被掃到」的狀態，先確認版本、必要時下線。

中風險，排進這週： 你在生產環境用 LangGraph 的 SQLite / Redis checkpointer，且過濾條件、metadata 之類的輸入有任何一段是使用者可控的；或你用了 langchain-experimental 裡會執行 LLM 生成程式碼的元件。

低風險，但別鬆懈： 你只用 LangChain core 做 prompt 組裝、且全在受信任邊界內，或你用的是 LangSmith 託管。風險低，但「升級到修補版」仍是基本盤。

更上位的決策是：編排層該放在哪裡、信任誰。 視覺化編排工具（Langflow 這類）的價值是讓非工程角色也能快速拼 flow，代價就是「flow 即程式碼」這個本質——它天生需要一條 code 執行路徑。把這種工具直接暴露在缺乏認證的網路位置，等於把 exec() 開放給全世界。能用託管就用託管；非自架不可，就把它關進嚴格的網路隔離與最小權限裡。

對工程團隊的意義：可以今天就做的事

盤點曝險面。 用內外網掃描確認有沒有 Langflow / LangChain 服務被非預期地對外開放，特別注意 build_public_tmp、validate/code 這類端點。曝險的優先處理。
對齊到「真正有修」的版本，不是「最新」。 依官方 advisory 指定版本升級（Langflow ≥ 1.9.0；LangChain / LangGraph 各套件版本見上節），升完用公開 PoC 或廠商提供的檢測重新驗證一次。
把編排層當成不可信邊界來部署。 預設拒絕外部存取、放進私有網段、加上認證與速率限制，別假設「內部工具沒人會打」。
掐住憑證爆炸半徑。 這次最痛的不是 RCE 本身，是環境變數裡那把 AWS key。改用短期憑證 / IAM role、把 secret 移出環境變數、為 agent 工作負載設定最小權限與可疑 API 呼叫的告警。
把「不可信輸入 → 執行路徑」列為架構審查項。 任何「LLM 生成 → 直接 exec/eval」、任何「外部資料 → 反序列化還原物件」、任何「使用者輸入 → 拼進 SQL」的地方，都要有沙箱、白名單反序列化或參數化查詢。這是這整批 CVE 教我們的同一課。