Langflow CVE-2026-0768：今年第 12 個在野外遭利用的 Langflow 漏洞

CVE-2026-0768 是 Langflow 中的一個未經身分驗證的遠端程式碼執行漏洞；Langflow 是用於組裝大型語言模型管線與代理的開源視覺化框架，而到 2026 年 8 月底，攻擊者已在實際環境中利用它。該漏洞位於 Langflow 自訂元件編輯器背後的程式碼驗證器中：validate 端點接受 code 參數並執行其中所含的 Python，無需驗證，且用 Zero Day Initiative 的說法，是「在 root 的環境中」。VulnCheck 的 Canary 蜜罐網路在 2026 年 8 月 30 日首次偵測後的數小時內，記錄到超過 50 次利用嘗試，到 9 月 1 日星期一已超過 360 次，全部針對英國的感測器；VulnCheck 的 Caitlin Condon 表示，來源流量主要來自俄羅斯。這些請求並非勒索軟體。它們讀取存放 Langflow 超級使用者憑證、OpenAI API 金鑰及 AWS 存取金鑰與私密金鑰的環境變數，接著查看 /root/.cache/langflow/secret_key、.ssh 與 .bash_history。該檔案庫對此事件的完整條目，包括其嚴重性、置信度與危害分類，收錄於Orca AI Incident Archive，與其周邊其他憑證竊取及 AI 基礎設施紀錄並列。

Security Affairs 於 2026 年 9 月 2 日發表其報導；SecurityWeek 的 Ionut Arghire 在前一天報導了該漏洞的實際利用情況，BleepingComputer 的 Bill Toulas 於該週跟進報導，而雲端安全聯盟（Cloud Security Alliance）的 AI 安全倡議則於 9 月 4 日隨後發布一份研究筆記，重述了該機制並補充建議。本文所檢視的各篇報導，均未指名任何受入侵的組織。所有內容都可追溯至 VulnCheck 自家的感測器，以及零日倡議（Zero Day Initiative）於 1 月發布的公告。

一個會執行被要求驗證內容的編輯器

Langflow 的賣點在於，你可以把元件拖曳到畫布上，藉此組裝出一個 AI 應用程式。自訂元件是以 Python 撰寫：編輯器讓使用者貼上程式碼並按下驗證，伺服器會檢查這段程式碼。根據 ZDI 公告 ZDI-26-034，這項檢查會執行程式碼。該公告的根因說明只有一句——「在使用者提供的字串被用來執行 Python 程式碼之前，缺乏適當驗證」——而結果是，單一未經身分驗證的 HTTP 請求就能在主機上執行任意 Python 程式碼。

有三個特性讓這件事成為資安事件，而不只是一份錯誤報告。CVSS 向量為 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H，評分 9.8：可經網路觸達、複雜度低、無需權限、無需使用者互動，且機密性、完整性與可用性全面喪失。執行環境是 root，因此 Condon 與雲端安全聯盟（Cloud Security Alliance）所描述的攻擊者指令，都指向 /root/.cache/langflow/secret_key——Langflow 用來加密存放的憑證與工作階段資料的檔案。而且該端點完全不要求任何憑證，因此是否暴露僅取決於能否觸達。

揭露的過程對這件事的發展有重要影響。ZDI 的時間線記錄了以下事件：報告於 2025 年 7 月 18 日送達 Langflow 的 GitHub 帳號、2025 年 9 月 11 日請求提供最新進展、2025 年 10 月 10 日請求提供修正，以及 2025 年 12 月 10 日通知打算以零日漏洞形式公布。ZDI 於 2026 年 1 月 9 日發布公告。獲列名的研究人員是 Trend Research 的 Peter Girnus、William Gamazo Sanchez 和 Alfredo Oliveira。GitHub 的公告資料庫收錄了相同文字，編號為 GHSA-x5pr-rvjj-j6qm，於 2026 年 1 月 23 日發布，分類為 CWE-94，且完全未列出任何受影響的版本範圍。ZDI 所述的緩解措施並非修補程式：而是「限制與該產品的互動」。

公開報導將受影響範圍指向 Langflow 1.4.2（含）之前的版本；後來加入的 Metasploit 模組，正是針對這個版本建置並測試。確定性僅止於此，下文關於修復的章節會說明原因。

360 項偵測能與不能證明什麼

VulnCheck 的 Canaries 是面向網際網路的感測器，刻意打造成看起來像攻擊者正在掃描的目標。該公司在 2026 年 8 月 29–30 日首次發現 CVE-2026-0768 遭到利用：週日幾小時內出現超過 50 次偵測，到週一攀升至超過 360 次。VulnCheck 威脅研究副總裁 Condon 在 LinkedIn 上將這波活動形容為「偵察與憑證蒐集的混合」，並補充說來源流量主要源自俄羅斯，且「迄今僅命中英國的 Canaries」。

感測器擷取到的命令序列具體到足以當成一套攻擊手冊。攻擊者查詢了環境中的 LANGFLOW_SUPERUSER、符合 OPENAI_API 的變數，以及 AWS_ACCESS 與 AWS_SECRET 金鑰——這是 Langflow 主機最可能持有的三類憑證。他們讀取了位於 /root/.cache/langflow/secret_key 的快取祕密金鑰。他們檢查了 .ssh 存取權，並檢視了 .bash_history 的大小；這兩者都能顯示操作者是否能橫向移動，而不只是讀取機密。一份經 Cloud Security Alliance 引用的社群文章針對這條攻擊鏈補充說，同一波活動還搜尋了原始碼樹與 .env 檔案中內嵌的機密、外洩所發現的內容，並在加入自身的持久化機制之前，檢查主機是否已遭先前的操作者植入後門。

這確立的是：該漏洞利用確實有效、曾被用於對網際網路可及的 Langflow 執行個體，且目標是憑證而非破壞。它並未確立的是受害者。金絲雀是誘餌；偵測到的是一次請求，而非已確認的竊取。檔案庫將此紀錄歸類為真實危害，而公開來源所記載的危害，是已確認的憑證竊取程式碼對暴露系統的執行——並非某個具名組織的金鑰遭到耗用。

有一個細節與外界對揭露的常見說法相悖。根據{{1}}VulnCheck{{/1}}，在利用行動開始時，{{2}}CVE-2026-0768{{/2}}並不存在公開的概念驗證。該公告已公開近八個月，且對該漏洞的描述精確到足以讓人依文本建構出漏洞利用程式。根據{{3}}The Hacker News{{/3}}報導，該公司的解讀是：這是獨立推導而來，而非重複使用外洩的程式碼。

十二項缺陷、一萬五千次嘗試——以及這些數字在何處失真

賦予這起事件份量的統計數據來自 VulnCheck，值得直接引用該公司自己的說法，而非轉述。該公司表示：「在 2026 年之前，證據顯示只有一個 Langflow 漏洞已知曾在實際環境中遭利用。」「到了 2026 年，情況迅速改變。」SecurityWeek 報導，VulnCheck 追蹤到 2026 年間「另有 11 個漏洞被鎖定並通報為已在實際環境中遭利用」。

把這些加起來，你會得到十二個已遭利用的 Langflow 漏洞，其中一個早於今年。這不等同於 2026 年的十二個，而來源在兩種表述之間游移。Forkast 的標題稱 CVE-2026-0768 為「Langflow 在 2026 年的第 12 個已遭利用 CVE」，而同一篇文章的正文則將這十二個描述為「11 個新漏洞，以及 1 個在年初之前已識別的漏洞」。該記錄的標題沿用標題的說法。嚴格解讀，2026 年佔這十二個中的十一個，而第十二個——也就是今年之前已知的那一個——構成其餘部分。

15,000 這個數字也具有類似的優勢。SecurityWeek、The Hacker News 和 Forkast 都將「超過 15,000 次成功攻擊」歸因於三個具名漏洞：CVE-2026-0769、CVE-2025-3248 和 CVE-2026-5027。這是個很大的數字，但它是橫跨三個 CVE 的計數，而非橫跨 Langflow 整個 2026 年漏洞組合的計數。將其表述為針對該組合的漏洞利用嘗試——如該檔案的摘要所做的那樣——比 VulnCheck 所發布的範圍更廣。

這個模式背後的個別條目已有記錄。根據 Cloud Security Alliance 引用的 GitHub 公告 GHSA-rvqx-wpfh-mfx7，CVE-2025-3248 是同一 /api/v1/validate/code 端點中的程式碼注入漏洞，已在 Langflow 1.3.0 中透過以僅編譯驗證取代執行來修補——這意味著 CVE-2026-0768 是同一程式碼路徑中的同一類錯誤，距離該修正發布大約四個月。CVE-2026-33017 是公開流程建置端點中的未經驗證 RCE，在 2026 年 3 月披露後約 20 小時內即被武器化，並被用來取得 OpenAI、Anthropic 和 AWS 憑證，隨後轉向門羅幣挖礦，這是 Cloud Security Alliance 的說法。同一聯盟於 2026 年 6 月 12 日的說明涵蓋 CVE-2026-5027，這是檔案上傳端點中的路徑遍歷漏洞，研究人員將其與伊朗國家支持的組織 MuddyWater 連結起來；而其 9 月 4 日的說明則記錄了 CVE-2026-55255，這是一種授權繞過，讓已驗證使用者能執行其他使用者的流程，並於 2026 年 7 月 7 日被列入 CISA 的已知遭利用漏洞目錄。這四者有一個共同形態：一個不是跳過驗證、就是跳過清理的端點，而所在平台的職責正是保管它與之通訊的一切憑證。

為什麼編排平台值得費這個功夫

正式環境的 Langflow 執行個體會配置供應商 API 金鑰、雲端憑證、資料庫連線字串與整合機密，因為其執行的工作流程在呼叫時需要這些項目。因此，一旦主機遭入侵，執行個體所儲存的每個服務憑證都會變成可用的存取權限。遭竊的 OpenAI 或 Anthropic 金鑰可讓攻擊者將推論費用記在受害者帳上，或在下游冒充該組織；遭竊的 AWS 金鑰則可開啟遠超出 Langflow 容器範圍的基礎設施。觀察到的命令所鎖定的正是這種槓桿效應，而非任何 AI 專屬能力。

雲端安全聯盟的判斷是：一年內在四個不同的 Langflow 子系統中反覆出現問題——程式碼驗證器、公開流程建置端點、檔案上傳、工作流程執行——這指向安全工程上的系統性缺口，而非一連串彼此無關的缺陷。這是該聯盟在一份研究報告中提出的評估，並非獨立稽核員的發現；而在本文檢視的資料中，Langflow 尚未公開回應此事。

哪些已修正，哪些仍不明確

這是公開紀錄中最薄弱的部分，值得精確說明原因。ZDI 的公告未指明任何修補版本。Snyk 對該 CVE 的資料庫條目將受影響版本列為 1.10.1 之前的所有版本，並建議升級至 1.10.1 或更高版本。包括 SecurityWeek 與 Security Affairs 的公開報導將受影響範圍描述為截至 1.4.2 的版本，但未指出任何已修復版本。Cloud Security Alliance 於 9 月 4 日指出，Langflow 的維護者尚未發布指名此 CVE 的專用安全公告，且各追蹤器對於哪個版本實際修復了該問題意見不一——該聯盟表示，這種模糊情況與先前的 Langflow 案例相呼應，當時一個被報導為已修復的版本仍可被利用。

Langflow 確實曾在正確的領域、正確的日子推出修正。版本 1.11.6 於 2026 年 9 月 1 日發布，當天是星期一，蜜罐數量突破 360，而其發行說明描述了安全性修正的回溯移植，包括「補上元件程式碼掃描的缺口」與「在不執行的情況下解析註解」（pull request 14876）。版本 1.12.0 於當晚隨後發布。同一程式碼路徑的進一步強化之後仍持續進行：較晚的一個 pull request 標題為「阻止 validate_code 執行匯入」，顯示在首次遭利用數週後，validate 端點仍在被收緊。這些都不構成廠商聲明 CVE-2026-0768 已在某個具名版本中修正，而在該紀錄所引用的來源中也找不到這類聲明。

攻擊者方面的變化更為清楚。針對該漏洞的 Metasploit 漏洞利用模組於 2026 年 9 月 2 日以拉取請求形式提交——同日 Security Affairs 刊出——並於 2026 年 10 月 8 日合併，且曾針對 Langflow 1.4.2 進行測試。無論最初的推導成果處於什麼狀態，在該漏洞開始遭到利用的六週後，利用此漏洞已不再需要原創性工作。

雲端安全聯盟（Cloud Security Alliance）建議的應變方式並非單純修補，而是「修補並輪換」的流程：確認目前執行中的版本，並升級至現行穩定版；凡受影響版本中任何對外暴露於網際網路的執行個體，在未經證實安全之前，都應視為已遭入侵，因為目前觀察到的活動是無聲的憑證蒐集，而非明顯的破壞行為；此外，還須輪換該執行個體所能觸及的所有機密資料——包括 Langflow 超級使用者密碼、各供應商的 API 金鑰、AWS 存取金鑰與私密金鑰，以及 Langflow 本身的密鑰，並且要重新加密已儲存的憑證，而不只是替換檔案。該聯盟也建議稽核存取日誌，查看是否有針對 validate 端點的請求，檢查 authorized_keys 中是否有陌生的 SSH 金鑰，並尋找先前操作者是否已在主機上植入後門的跡象。若該平台必須持續對外提供服務，則建議對 validate 端點進行存取管制或予以停用，並捨棄直接存放在平台上的長期高權限金鑰。

已確立、已通報，以及未確立

已確認：CVE-2026-0768 是 Langflow validate 端點中的未經驗證 RCE，會以 root 權限執行 Python，記錄於 ZDI-26-034，並以 GHSA-x5pr-rvjj-j6qm 鏡像收錄；利用活動始於 2026 年 8 月 29–30 日；VulnCheck 在數小時內記錄到超過 50 次偵測，至 9 月 1 日已超過 360 次，針對英國感測器，流量主要來自俄羅斯；且觀察到的請求鎖定 Langflow 超級使用者、OpenAI 與 AWS 憑證，以及快取的秘密金鑰、.ssh 與 .bash_history。這些內容來自公告本身，以及 VulnCheck 的遙測資料，並由 SecurityWeek、Security Affairs 與 The Hacker News 獨立報導。

據報，未經獨立核實：每一項偵測計數。50、360 與 15,000 都是 VulnCheck 自家的數字，由該公司公布，並經註明其為消息來源的媒體轉載；沒有任何第二個蜜罐網絡發表過可佐證的計數。將其歸因於俄羅斯基礎設施，同樣只是 VulnCheck 對來源流量的解讀，而非任何政府或 CERT 在已審閱資料中所認可的評估。

未經證實：任何具名組織遺失憑證。該紀錄的來源中並未識別出任何受害者。也沒有已確認的修補版本：ZDI 未指名任何版本，Snyk 表示為 1.10.1，報導稱受影響至 1.4.2，而 1.11.6 的發行說明描述了安全性修正，卻未將其與此 CVE 連結。此外，「2026 年第十二個漏洞」的計數在其自身來源之間也不一致，如上所述。

真正該讓按既定時程修補的人擔憂的部分

這八個月的空窗期本身就是這項發現。CVE-2026-0768 於 2026 年 1 月 9 日以零日漏洞形式公布，其技術描述詳盡到足以據此重建，而 VulnCheck 的感測器直到 8 月最後一個週末才有了動靜。接著三天內湧入數百次嘗試，根據該公司的說法，這些操作者並沒有公開的漏洞利用程式可抄。無論是什麼讓那些執行個體在公開重大公告發布後的八個月裡始終未修補，也正是當有人終於寫出程式碼時，讓這個漏洞值得利用的原因。

這也讓早先 Langflow CVE 所開啟的迴圈得以閉合。CVE-2025-3248 的修補方式是從同一個驗證路徑中移除執行行為；CVE-2026-0768 卻仍在那條路徑上執行。只移除行為、卻未移除產生該行為的設計決策，這種修補只能爭取時間；而在這個案例中，它爭取到大約四個月的時間。