CVE-2026-9198：Langflow 為任何人簽發超級使用者權杖，然後執行他們送出的內容

IBM 針對 CVE-2026-9198 的公告描述了對 Langflow OSS 的兩次請求接管：對該平台自動登入端點的一次呼叫，會向任何提出要求者回傳超級使用者 bearer token；第二次呼叫則將 Python 提交至程式碼驗證端點，而該端點會執行它。供應商將這條鏈的兩半分別歸在獨立識別碼之下——CVE-2026-9103 用於缺少驗證，CVE-2026-8481 用於執行——並在 CVSS 3.1 上將此組合評為 9.8，可從網路觸及，且無需任何權限或使用者互動。1.0.0 至 1.10.0 版本的預設部署會受影響；修復版本為 1.10.1，而 IBM 未列出任何變通方案。美國網路安全暨基礎設施安全局於 2026 年 8 月 4 日將該 CVE 加入其已知遭利用漏洞目錄，聯邦修復期限為 8 月 7 日。該紀錄、其嚴重性與危害標籤，以及圍繞它歸檔的條目，均保存在 the Orca AI Incident Archive，該檔案將此事件與該系列其餘部分並列列出。

這條鏈，見於三份 IBM 公報

IBM 將此漏洞發布為三份文件而非一份，而唯有將它們合併閱讀，才能讓其機制清晰可辨。整條鏈是 CVE-2026-9198，這是一個屬於 CWE-94 的程式碼注入問題，評分為 9.8，向量為 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H——可從網路觸達、低複雜度、無需權限、無需使用者互動，且對機密性、完整性與可用性有高影響。它的前半部分是 CVE-2026-9103，屬於 CWE-306 的關鍵功能缺少身分驗證，評分同樣是 9.8。它的後半部分是 CVE-2026-8481，同樣是 CWE-94，但評分為 9.9：AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H，所需權限為低而非無，且範圍已變更。

9.9 是這套算術中誠實的部分。程式碼驗證端點本身從來不對陌生人開放——IBM 將其描述為一個缺陷，讓「任何已驗證使用者都能以 Langflow 伺服器程序的完整權限執行任意系統命令」。讓這條攻擊鏈得以在未經驗證的情況下運作的，是前半段：自動登入端點；在 IBM 的說法中，當 AUTO_LOGIN 組態啟用時（預設為啟用），該端點「會發放長效的超級使用者 bearer 權杖，且不要求驗證」。公告還指出，這些權杖具有 365 天的有效期限，並記錄了第二條較少受到關注的暴露途徑——寬鬆的跨來源資源共用預設值，允許帶有憑證的萬用字元來源；IBM 表示這「可能讓任意網站得以進行路過式權杖竊取」。

執行那一半才是值得細究的部分。IBM 的摘要指出，驗證器「編譯並執行使用者提交的程式碼，包括函式定義時期的求值，例如預設引數與裝飾器」，因此攻擊者可以把可執行運算式夾帶進預設參數或裝飾器裡。這不是在說不安全程式碼的比喻：裝飾器會在包住它的 def 被建構時求值，所以一個唯一明示目的只是檢查函式語法的請求，仍會執行附掛在其上的任何東西。IBM 自己的連鎖公告用一個子句就表達了這一點——驗證與執行是同一項操作。CVE-2026-8481 公告記載的修復方式是「從驗證路徑移除程式碼執行，只執行編譯檢查」。

有一個小出入值得記錄，因為它會影響狩獵。串連公告將權杖端點寫成 /api/v1/auto_login，Cloud Security Alliance 和 Field Effect 也是如此；IBM 另行發布的 CVE-2026-9103 公告則寫成 /api/v1/login/auto_login。兩份 IBM 文件描述的是同一個端點，且兩者對行為的描述都沒有錯。執行路徑在各處的寫法完全相同：POST /api/v1/validate/code。

日期來源何處

檔案將此紀錄的日期定為 2026 年 8 月 6 日。CISA 的目錄條目於 2026 年 10 月 30 日查閱時，記載新增日期為 2026 年 8 月 4 日，並將修復截止日定為 8 月 7 日。周邊報導落在檔案日期的兩側，而非當天：Field Effect 於 8 月 5 日發布，cvetodo 與泰國國家電腦緊急應變小組則都於 8 月 7 日發布。一筆收錄、它產生的截止日，以及針對它撰寫的文章，是三件不同的事件，因此這些日期並不互相矛盾——但檔案欄位與 CISA 欄位之間的兩天落差，正是當確切日期很重要時需要查閱目錄的原因。

披露一事更难确切判定，且消息来源也确实存在分歧。IBM 关于该链式 CVE 的公告页面所载的初始发布日期为 2026年7月2日，修改日期为 2026年8月17日。Field Effect 将 IBM 的披露日期定为 7月2日。Cloud Security Alliance 8月18日的研究笔记将披露时间以及随之发布的 1.10.1 定在 7月17日；cvetodo 的说法相同。两种解读相差十五天，而两份文件也都并非草率之作，因此本文不在两者之间作出取舍。无论按哪种说法，可以确定的是：补丁在 KEV 列入之前就已发布，而 1.10.1 正是承载该补丁的版本。

CISA 的條目在其自身欄位中確切所述的內容，比其標題更為狹隘。該產品列於廠商 IBM 之下，產品為 Langflow；該漏洞被描述為「可讓未經身分驗證的攻擊者在預設 Langflow 部署上達成完整的遠端程式碼執行」；已知用於勒索軟體活動的紀錄為 Unknown；依 BOD 26-04 要求必須進行鑑識初步篩檢；而必要行動是依廠商指示套用緩解措施，或在無法取得緩解措施時停止使用該產品。

利用記錄

CISA 的清單聲稱該漏洞已遭實際利用。然而，支持這項說法的公開證據，比 9.8 這個評分所暗示的還要薄弱。IBM 與 CISA 均未指名任何威脅行為者，也未公布所觀察到的攻擊活動細節——Field Effect 已明確指出這點，而 IBM 的三份公告或 KEV 收錄條目中，也沒有任何內容與此相牴觸。

相反，目前存在的是經二手轉述的廠商遙測資料。雲端安全聯盟（Cloud Security Alliance）的說明引述 KEVIntel 的說法，指攻擊嘗試記錄始於「2026年7月6日前後」；依該聯盟自身的推算，這比揭露時間早了數週，且截至8月中旬，累計嘗試次數已增至數百次，來源是分散於數十個國家、數百個不重複的網際網路位址。這些數字來自單一監控公司，並未出現在本文檢視的其他任何來源中。本文僅報導這些數字，並未予以佐證。

開始日期值得再次審視。若嘗試確實始於 7 月 6 日前後，那會是 IBM 頁面所載公告日期之後四天，也是另外兩個來源所給的 7 月 17 日之前十一天。因此，遙測資料既無法證實、也無法否定這兩個披露日期中的任何一個；Cloud Security Alliance 提出兩種解釋卻未從中選擇，將早期活動描述為機會主義掃描者的獨立發現，或是協同披露前的技術細節外洩。

公開漏洞利用程式碼是記錄得較完整的一部分。Field Effect 將該攻擊鏈的公開描述歸因於「一份於 2026 年 7 月公開的概念驗證」，其位於儲存庫 github.com/0xdak/CVE-2026-9198_exploit，並表示該程式碼示範透過自動登入端點取得超級使用者權杖，再將其用於驗證端點。Field Effect 並未將該儲存庫的作者與任何觀察到的漏洞利用行為建立關聯，本文也沒有。任何已檢視的來源同樣未報導從遭利用主機確認竊取憑證的情事：一般而言，伴隨 Langflow 漏洞出現的憑證蒐集描述，是對這類主機可能持有何物的評估（下文會說明），而非針對本紀錄中任何具名受害者的調查發現。

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

• 已確認。CVE-2026-9198 將自動登入端點中缺少身分驗證的問題，與程式碼驗證端點中的程式碼執行串連起來；IBM 依 CWE-94 將此攻擊鏈評為 9.8，而其兩個組成部分分別為 9.8 與 9.9；Langflow OSS 1.0.0 至 1.10.0 的預設部署在 Windows、macOS 與 Linux 上均受影響；1.10.1 是修復版本，且 IBM 未公布任何因應措施；CISA 已將該 CVE 加入 KEV 目錄，聯邦期限為 2026 年 8 月 7 日。這三份 IBM 公告是主要文件，且它們對該機制的說法一致。

• 獨立重述。 ThaiCERT 在其 2026 年 8 月 7 日的公告中重現了相同的雙端點鏈、相同的 9.8 評分、相同的受影響範圍以及相同的 1.10.1 補救措施，並新增了一項 IBM 公告中未提及的網路控制措施：讓 Langflow 的管理介面遠離公開網際網路，僅能透過 VPN 或嚴格的位址允許清單存取。這印證了該公告是如何被解讀的，且是由一個與廠商措辭無利害關係的政府機構所為——並非對該漏洞的獨立發現。

• 已有報導，但未經證實。各項利用統計數字：數百次嘗試、數百個位址、數十個國家，始於約7月6日。這些是單一監控公司的數據，由一個研究機構轉述。CISA的清單確認了利用行為確實發生，卻未加以量化，而在此處檢視的材料中並未出現第二個遙測來源。

• 尚未確立。沒有指名的受害者，也沒有指名的行為者。未歸因於任何國家或犯罪集團。沒有確認有多少個 Langflow 執行個體可從網際網路存取——cvetodo 於 8 月 7 日報導，IBM 尚未回答有關利用規模的問題——此後也沒有廠商聲明量化此情形。檔案庫將此紀錄評為信心等級 A，且未標記為有爭議，此處所審查的內容也沒有對其提出異議；這些缺口是公開證據中的缺口，而非「該漏洞存在且已被利用」這項主張的缺口。

• 刻意排除。ThaiCERT 的公告也描述了同一週由 AI 主導的自動化掃描，但將其歸屬於同一 CISA 批次中的另一項產品，而非 Langflow。這並非關於本紀錄的證據，因此在此也不作為此類證據使用。

上市後有什麼變化？

廠商的補救措施就是升級版本，別無其他。IBM 的受影響產品表列出 Langflow OSS 1.0.0 至 1.10.0，指明 1.10.1 為修正版本，並在因應措施欄位填上「None」——三份公告皆然。CVE-2026-8481 公告說明了這項變更：驗證器停止執行，改為編譯。涵蓋自動登入部分的 CVE-2026-9103 公告，則未同樣詳細說明其修正內容，且此處檢視的 IBM 文件均未載明 1.10.1 版的發布日期。

其他所有人的指引都比廠商更進一步。Cloud Security Alliance 建議先升級，接著在執行階段驗證自動登入端點不再對未經身分驗證的呼叫者發行權杖，而不是只信任版本字串——其所述理由是，先前的 Langflow 修補程式推出時修復並不完整。它也建議明確將 LANGFLOW_AUTO_LOGIN 環境設定設為 false，讓平台要求真實憑證，而不是自行核發憑證；並將任何自七月初以來曾對網際網路開放的執行個體，在日誌審查完成前都視為已遭入侵，同時輪換該執行個體所能觸及的一切憑證：模型供應商金鑰、資料庫憑證與雲端服務金鑰。ThaiCERT 則補上網路層面的部分——不得將管理介面暴露於公開網際網路，僅限透過 VPN 或允許清單存取。兩者皆為研究人員的建議。IBM 未發布任何建議。

紀錄中有一筆致謝資訊。IBM 的致謝將該報告歸功於 Harish Kolla，其 GitHub 帳號為 Har1sh-k。雲端安全聯盟（Cloud Security Alliance）在 8 月 18 日的說明中，將 CVE-2026-9198 列為大約五個月內第四個進入 CISA 目錄的不同 Langflow 漏洞，這些漏洞屬於未經身分驗證或授權繞過類型；該聯盟同時列出先前三個識別碼。其解讀是，這個模式反映的是對同一套身分驗證與程式碼執行模型反覆進行零碎修補，而非互不相關的缺陷。那樣的框架是該聯盟的評估，發表於一份研究報告中；這不是獨立稽核者的發現，而本文檢視的來源中，沒有任何來源記錄維護者對此的公開回應。

KEV 清單釐清了什麼，又沒釐清什麼

CISA 的目錄是對已觀察到利用行為的斷言，而非事件報告，而本條目維持此一形式。它指出該漏洞曾被利用；但未說明利用者是誰、針對誰，或利用頻率為何。勒索軟體的使用情形記錄為未知。沒有任何量化。這份清單確實釐清的，是嚴重性評分無法回答的那個唯一問題：該漏洞是否已從可運作的概念驗證轉為實際使用。對於不受 BOD 26-04 適用範圍約束的組織——而這是世界上大多數組織——8 月 7 日的期限不帶來任何義務，而支撐該期限的事實，其份量與存在義務時並無二致。

雲端安全聯盟從同一個條目得出實務結論：列入 KEV 清單是漏洞利用已通過概念驗證階段的可靠訊號，而就這個漏洞而言，這項訊號大約在首批有紀錄的嘗試出現一個月後才到來。照這種解讀，任何人若等到該目錄公布才進行分流處置，就已經是在回應事件，而不是在預防事件。這是否適用於某個特定部署，得看它的日誌——要搜尋的端點配對就是 IBM 所記錄的那一組，而該紀錄並未指名任何受害者，可供對照驗證答案。