IBM 的 Payment Agent 接受未經身分驗證的 Runbook 寫入 — CVE-2026-18875

IBM 披露其支付平台 IBM Financial Transaction Manager 的 AI 代理程式伺服器存在一項漏洞：沒有憑證的呼叫者可將自行選擇的執行手冊寫入該代理程式所檢索的向量資料庫，隨後代理程式本身的 Model Context Protocol 工具呼叫便可受其讀取的內容所操控。IBM 於 2026 年 9 月 21 日發布的安全公告指出，該漏洞可能導致 「未經授權的付款操作或外洩付款資料。」該 CVE（CVE-2026-18875）於 2026 年 9 月 23 日發布，CVSS 3.1 基礎分數為 7.3，對應至 CWE-74，且位於 api.vectordb.runbooks.js:51。目前尚未記錄到任何在野利用情形，也沒有任何客戶、付款或資料損失被歸因於此漏洞。本記述摘自下列來源中的單一條目：Orca AI Incident Archive，該檔案庫將 CVE-2026-18875 記錄為中度嚴重性漏洞，未記錄任何損害，並將其與其他已記錄的代理程式事件並列。

一份收錄四十七個 CVE 的公報中的一個 CVE

IBM 對此漏洞的公告並非獨立通知。它只是安全公告：IBM Financial Transaction Manager (FTM) 受多個弱點影響中的一則條目，文件 UID 為 ibm17288641，其受影響產品與補救措施表格涵蓋此批次中的所有 CVE。該頁面載有 47 個不同的 CVE 識別碼，IBM 評分從 3.7 到 9.9，且其變更歷程僅有一行：「2026年9月21日：初次發布。」該公告發布後未經修訂，且其致謝章節為空白——IBM 未就這 47 項發現向任何研究人員、通報者或客戶致謝。

RAG 條目是該清單中的異類。鄰近的 CVE 描述大多讀起來像一般的中介軟體安全衛生措施：硬編碼加密金鑰、路徑遍歷、XML 外部實體處理、不安全的反序列化，以及一項缺失的授權檢查，IBM 表示這「可能允許遠端攻擊者執行未經授權的付款操作」。CVE-2026-18875 是唯一描述產品 AI 代理如何取得其推理所用材料之缺陷的條目。IBM 的描述，完整引用自該公告：

IBM Financial Transaction Manager（FTM）4.x 的 FTM AI 代理伺服器（api.vectordb.runbooks.js:51）存在可透過未經身分驗證的 runbook upsert（CWE-74）發動 RAG 投毒的漏洞。未經身分驗證的攻擊者可將惡意 runbook 內容插入代理的向量資料庫，藉此操控由 AI 驅動的 MCP 工具呼叫，進而可能觸發未經授權的付款動作或外洩付款資料。

這些日期值得分開說明，因為公告與公報所用的日期並不一致。IBM 的公報所載的初始發布日期為 2026 年 9 月 21 日。CVE 識別碼於 2026 年 8 月 4 日保留，而 CVE 紀錄本身則於 2026 年 9 月 23 日 15:47 UTC 發布；NVD 的條目則於同日 16:16 UTC 隨後刊出。該檔案以日為精度，將此事件記載於 2026 年 9 月 23 日，亦即 CVE 公開當日。

機制：寫入代理程式所信任的儲存庫

檢索增強生成系統的運作方式是從儲存庫中取出段落，並將它們放在模型前方作為上下文。IBM 的公告將一個「runbook upsert」函式放在該層中——這是一項會將 runbook 項目寫入代理程式向量資料庫的操作——並表示該操作在未經驗證的情況下接受了寫入。公告中的路徑 api.vectordb.runbooks.js:51 指向一個 JavaScript 服務，而這就是 IBM 所披露的全部架構資訊。

這使得此事與大多數代理事件所圍繞的間接提示注入成為不同的命題。在一般情況下，攻擊者必須讓內容出現在瀏覽或讀取檔案的代理面前：對代理將抓取的頁面、它將開啟的文件、它將摘要的電子郵件投毒。在這裡，無需從外部抓取任何東西。攻擊者將受毒化的知識直接寫入代理已信任的儲存庫，而該儲存庫在付款工作流程中將其作為已審核的操作指引交回。Redbot Security 是一家威脅情報公司，將該漏洞記錄為 RBT-TI-0099，並將其定性為具零點擊資料外洩的間接提示注入；它用一句話點出這項區別：「檢索到的內容可能成為一種操作影響力。」該檔案庫出於同樣理由將此記錄標記為 IPI 和 INFRA——注入路徑是代理的指令層，而漏洞存在於基礎設施中。

IBM 沒說的事，和它說了什麼同樣重要。這份公告並未點名該代理程式可呼叫哪些 MCP 工具，也未說明這些工具會觸及哪些付款作業，更未交代 upsert 路由是在預設的 FTM 部署中就會暴露，還是僅限於特定組態，同時也沒有描述原本應該用來守護它的身分驗證模型。它只說「有可能」，然後就到此為止。

閱讀 7.3

CVSS 3.1 向量為 AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L。拆解後：可透過網路觸達、攻擊複雜度低、無需權限、無需使用者互動——這正是其嚴重之處——而機密性、完整性與可用性影響皆為低，作用範圍不變。IBM 自身數據將可利用性評為 3.9，影響評為 3.4。IBM 評估的每個影響面向皆為 Low。7.3 這個分數幾乎完全是由該漏洞的易觸達程度所撐起，而不是由 IBM 認為它會造成多大損害所支撐。

IBM 是唯一對其評分的單位。NVD 截至 2026 年 10 月 7 日將 CVE-2026-18875 標記為「Analyzed」，但其紀錄上唯一的 CVSS 指標是 IBM 的，標記為 Secondary；NVD 並未提供自己的主要分數。GitHub 的 Advisory Database 刊載相同的描述與相同的 7.3，發布於 2026 年 9 月 23 日 18:31 UTC。

最接近 IBM 未撰寫之評估的內容，來自 CISA 在 CVE 記錄上的 ADP Vulnrichment 區塊，那是 SSVC 2.0.3 於 2026 年 9 月 23 日 18:48 UTC 記錄的一項判定：利用情形：無。可自動化：是。技術影響：部分。 這項判定同時說明兩件事，而兩者都應放在同一句話裡：CISA 的協調人員在發布時未見任何利用情形，並認為該漏洞可自動化——也就是掃描器或腳本可處理的那類漏洞，而非一次性的人工攻擊。

FIRST 的 Exploit Prediction Scoring System 在 2026 年 10 月 25 日的模型執行中，將 CVE-2026-18875 評為 0.00369，約 0.37%，位於第 30 百分位。EPSS 估計未來 30 天內觀察到漏洞利用的機率；第 30 百分位的分數是個不起眼的數字，而且它是預測，並非任何已發生事件的報告。

什麼是已經確立的，什麼不是

已確認。該漏洞存在，且記載於彼此一致的原始來源中：IBM 於 2026 年 9 月 21 日發布的公報、2026 年 9 月 23 日發布的 CVE 記錄、NVD 的分析條目，以及 GitHub 的安全公告。受影響版本範圍、修正版本、CVSS 分數與向量、CWE 對應關係及程式碼位置在這些來源中完全相同。該寫入路徑無需憑證即可觸達——這見於 IBM 本身的描述，而非從分數推斷。CISA 的協調人員記錄為未遭利用。該檔案將記錄信心評為 A、無爭議，並將實際損害記錄為 false。

• 此漏洞。FTM AI 代理伺服器中 api.vectordb.runbooks.js:51 的未經驗證 runbook upsert，讓攻擊者能將內容插入代理所檢索的向量資料庫。這是 IBM 的原文措辭，並非重新建構。

• IBM 所聲稱的後果。這類受污染的內容可能引導 MCP 工具呼叫走向未經授權的付款操作，或造成付款資料外洩。IBM 將此陳述為一種可能結果；並未聲稱已在客戶環境中實際展示。

• 此修正程式。 FTM 4.0.11.0，引用自 IBM 支援節點 7285661。公告的「因應措施與緩解措施」欄位顯示為「無」。

• 利用紀錄。無。CISA 於 2026 年 9 月 23 日的 SSVC 紀錄載明 Exploitation：none；截至 2026 年 10 月 25 日的 EPSS 數值 0.37% 是預測，而非觀察；在已審查的任何來源中，均未出現受害者、交易或損失。

尚未確認。 是誰發現該漏洞、如何發現——公告未註明任何人，也沒有具名研究人員的公開報告。易受攻擊的路由是在預設部署中就會暴露，或僅在特定組態下才會暴露。4.0.11.0 實際上改變了什麼：upsert 路由現在是否需要驗證、是否已被移除，或以其他方式縮小了範圍。是否有任何 FTM 部署曾將該端點暴露給不受信任的網路，以及從 8 月 4 日保留到 9 月 23 日發布之間持續了多久。以及 IBM 警告的付款動作是否曾在任何地方被嘗試過。

次要追蹤器中的版本範圍並不一致。有些將受影響範圍表示為「4.0.6.0 及更早版本」，這與 IBM 公布的不符；其他則給出 4.0.7.0 到 4.0.11.0（不含 4.0.11.0），這與 NVD 的機器可讀設定相符，但省略了 4.0.6.0 的臨時修補版本線。IBM 的公報在此具權威性，並列出上方卡片所轉載的六個版本線。

還有一件事尚未獲得確立，因為沒有人嘗試去確立它：似乎沒有任何主流新聞機構或獨立研究實驗室發表過自己對 CVE-2026-18875 的分析。在公開紀錄中，唯一並非由 IBM 撰寫的評估，就是 CISA 的三欄位 SSVC 區塊。截至 2026 年 10 月 26 日，相關報導僅包括 IBM 的公告、CVE 紀錄、NVD、GitHub 的資安公告，以及一批複製 IBM 原文的漏洞追蹤器。關於此 CVE 的若干搜尋結果，是出處不明的部落格文章，讀起來像是機器生成的內容，其中有些還發布在同時刊登加密貨幣價格小工具的網站上；本文並未採用其中任何一篇作為來源。關於這個漏洞，並不存在第二份獨立的記述。

修正方案，以及其後的落差

IBM 的補救措施只有版本升級這一項，別無其他：將 Red Hat OpenShift 部署的 FTM 更新至 4.0.11.0，首個修正位於支援節點 7285661，且未提供任何過渡期替代方案。最後這一點才是實務上真正重要的。當廠商在「替代方案」欄位下僅註明「None」，對於無法配合支付時程升級到 4.0.11.0 的營運人員而言，就只剩下廠商未白紙黑字寫下的措施——限制誰能存取代理伺服器的 runbook 介面，而這是 Redbot Security 建議、IBM 卻未建議的做法。

風險有多大，取決於 FTM 究竟是什麼。IBM 將其描述為「一個統一的支付樞紐，能安全地處理、監控並管理所有支付類型，包括批次與即時模式」，並支援 ISO 20022 來處理與路由交易，另有搭配的 SWIFT 產品可提供經認證的 SWIFT 連線。IBM 產品頁面還宣傳 FTM AI Assistant，這是一個「具代理能力、由生成式 AI 驅動的對話式介面」，涵蓋支付、核准、系統效能與文件。該公告指出「FTM AI agent server」是漏洞所在位置，卻隻字未提該伺服器與行銷頁面上的助理有何關係。任何人若把這兩份文件合在一起畫架構圖，都只能靠猜。

Redbot 從此案例得出的設計教訓，是修補後依然成立的那一項：讓擷取到的內容遠離授權路徑。其建議是：建立、替換與刪除執行手冊都須經過身分驗證、核准與來源歸屬確認；擷取到的執行手冊絕不得自行授權付款、擴大交易範圍或允許外部資料傳輸；且無論代理程式如何解讀其所擷取到的內容，所連結的付款服務都應強制執行自身的權限。這些是某家威脅情報公司的建議，並非 IBM 的承諾，而 IBM 的公報完全沒有作出其中任何一項承諾。

為什麼檔案館稱它為「中型」

紀錄與 CVSS 分數回答的是不同問題，而兩者之間的落差，就是本案最誠實的總結。IBM 的 7.3 是針對一個可輕易觸及的瑕疵所給出的 HIGH 級距分數。檔案庫將該條目記錄為漏洞而非事件，嚴重性為中，實際危害為否，信心水準為 A，且沒有爭議標記，日期為 2026 年 9 月 23 日，精確到當天，並以全球區域欄位歸檔。這些欄位描述發生了什麼事，而發生的事就是什麼也沒有。

那個組合正是這筆記錄的重點。一個會從任何人都能寫入的儲存區讀取資料的付款代理，是一項嚴謹的工程之作，而且在已知有人使用它之前，就已於版本升級中修正。兩半都是真的，而記錄讓它們保持分開，而不是讓分數或沉默獨自發聲。