Langflow未修補RCE遭利用：AI工作流的金鑰風險

圖片：TechLab 自製資訊圖

TechLab 編輯部（譯）·2026-09-04

Langflow一項仍未有修補程式的嚴重漏洞CVE-2026-0768，已出現實際利用嘗試。iThome報道引述威脅情報公司VulnCheck指出，研究人員在8月底發現針對此漏洞的活動；攻擊者所查詢的環境變數，顯示其目標包括OpenAI API金鑰及AWS機密資料。對以Langflow串連模型、雲端服務與內部資料來源的開發者而言，這不僅是單一伺服器失陷的風險，亦可能令第三方 AI 帳戶及雲端資源遭濫用。

最重要的限制是：這宗事件所見的是蜜罐中的利用嘗試，並非已獲確認的大規模入侵個案。iThome報道稱，VulnCheck在逾50個蜜罐觀察到相關流量，部分活動似乎同時進行偵察及憑證蒐集；報道亦提及目標主要位於英國的加那利群島、流量大多來自俄羅斯。這些觀察能說明漏洞已進入攻擊者視野，卻不足以推斷任何特定地區、公司或實際Langflow用戶已遭入侵。

漏洞為何會直指AI工作流的核心資產

CVE-2026-0768屬於未經身分驗證的遠端程式碼執行漏洞，CVSS評分為9.8。iThome指出，問題位於Langflow自訂元件編輯器的程式碼驗證工具：驗證端點接收的程式碼參數，在執行Python程式碼前未獲適當驗證。根據Zero Day Initiative（ZDI）披露的資料，攻擊者可藉此以root權限執行程式碼。換言之，風險不局限於某個flow設定出錯，而是外部人士可能在無須先登入的情況下，取得部署主機的高權限控制。

Langflow常被用作把大型語言模型、資料庫、工具調用及雲端服務串成可視化流程。這種便利亦令憑證容易集中在同一執行環境：OpenAI API金鑰可能用於模型調用，AWS憑證可連接儲存、資料服務或其他雲端資源。若伺服器的環境變數可被讀取，攻擊者未必需要破解每項下游服務，已可能直接取得可用的存取權。這是根據iThome所載攻擊者查詢目標作出的風險分析，並非指所有Langflow部署均以同樣方式保存金鑰。

未有補丁時，先把可達性降至最低

ZDI早在去年7月通報此問題，並在今年1月公開詳情；截至iThome報道刊出時，漏洞仍未修補。報道亦引述ZDI的判斷：基於漏洞性質，有效的緩解方向是限制與產品的互動。這項建議的重點相當直接：若Langflow的編輯、驗證或管理介面能從公網直接存取，團隊應把它視為優先處理的暴露面，而非等待日後更新才處置。

實際部署上，團隊可先盤點所有Langflow實例，尤其是測試環境、個人雲端主機、短期概念驗證與遺留伺服器，因為這些位置最容易在完成開發後仍保留對外入口。把管理與開發介面移離公網，改為只容許受信任的內部網絡、VPN或其他受控存取路徑，可減少未經驗證請求直接觸及受影響功能的機會。若某實例無法即時完成隔離，暫停對外服務或停用相關互動功能，通常比維持便利接入更合乎目前風險狀況。

金鑰輪換不能只停在更換一組字串

由於觀察到的攻擊目的包含OpenAI與AWS機密資料，已將這些憑證放入可能受影響Langflow主機的團隊，應評估立即輪換。輪換應涵蓋直接寫在環境變數、部署設定、CI/CD流程或相連secret管理機制中的憑證；舊金鑰則應盡快撤銷。單純建立新金鑰但保留舊金鑰有效，會令已外洩的存取權繼續存在，也令調查難以分辨新舊憑證的使用情況。

輪換後亦要核對新憑證的權限範圍。從防護角度分析，若AI工作流只需要調用某項模型或存取指定資源，便不應讓它同時持有更廣泛的雲端管理權限。這種最小權限安排雖不能消除 Langflow 漏洞，卻可縮窄憑證外洩後可能造成的影響範圍。團隊同時應檢視相關帳戶及雲端服務的存取紀錄，留意異常API調用、未知來源的資源操作或不合預期的金鑰使用；一旦發現可疑跡象，應按既有事故應變程序處理。

部署檢查應覆蓋開發與營運兩端

開發團隊可把今次事件轉化為一張短期檢查清單：確認有沒有對外公開的Langflow實例；確認哪些主機可能受CVE-2026-0768影響；限制管理及程式碼驗證功能的可達性；列出該環境可接觸的OpenAI、AWS及其他服務憑證；完成輪換和撤銷；再檢查新憑證是否遵守最小權限。清單的價值在於將「修補未到」這個外部限制，拆成營運團隊現在已能執行的工作。

對香港公司、開發者及學生而言，是否受影響取決於有否自行部署Langflow、部署版本及介面暴露方式，而不取決於所在地。尤其是在實驗性AI專案中，將金鑰放進環境變數、以公網伺服器快速展示flow，都是常見的開發便利安排；在嚴重未修補漏洞出現利用跡象時，這些安排需要重新審視。iThome亦提到，現時尚未有公開的概念驗證程式碼，然而這不應被理解為可延後防護的理由，因為VulnCheck已記錄到真實攻擊流量。

下一步應留意Langflow是否發布修補程式，以及ZDI與VulnCheck有否更新受影響範圍、利用活動或緩解建議。在此之前，負責AI flow、雲端帳戶及secret管理的人員應共同處理問題：開發者知道流程如何運作，基礎設施團隊掌握入口與伺服器，安全人員則可追蹤憑證使用和異常活動。把這三者連起來，才能在修補程式尚未到位的期間，較有把握地控制風險。