IBM Financial Transaction Manager（FTM）這次揭露的重點，不只是「AI 又多一個漏洞」，而是企業把檢索資料、語言模型與可執行工具串在一起後，原本被視為參考資料的文字，可能一路變成付款或資料存取指令。這使 RAG 資料庫的寫入權限，升格為交易系統的安全邊界。
事件背景：一個分數不是最高、後果卻特殊的漏洞
來源事實：Forkast 報導指出，CVE-2026-18875 位於 FTM 4.x 的 AI agent server，未經驗證的攻擊者可透過 runbook upsert，把惡意內容寫進代理程式使用的向量資料庫；IBM 給予 CVSS 3.1 基礎分數 7.3。原始報導見 https://forkast.news/unauthenticated-rag-poisoning-in-ibm-financial-transaction-manager-exposes-mcp-tool-calls-to-hijacking/。
IBM 官方公告進一步確認，問題位於 api.vectordb.runbooks.js:51，惡意 runbook 內容可能引導 AI 驅動的 MCP 工具呼叫，潛在結果包括未授權付款或付款資料外洩。受影響的是 Red Hat OpenShift 上的 FTM 4.0.6.0 至 4.0.10.0，以及公告列出的 4.0.6.0 iFix6 相關版本；修正版為 4.0.11.0，而且 IBM 明列沒有替代性 workaround。官方公告：https://www.ibm.com/support/pages/node/7288641。
日期則有一處值得校正：Forkast 稱 IBM 於 9 月 23 日發布公告，但 IBM 頁面記載初次發布與修改日期均為 9 月 21 日；CVE 資料則在 9 月 23 日發布。這不改變漏洞內容，卻提醒讀者不要把新聞稿日期、供應商公告日期與 CVE 登錄日期混為一談。
攻擊如何跨過「資料」與「行動」的界線
RAG 的基本做法，是先從文件或向量資料庫找出與問題相關的內容，再把內容送進模型的上下文。正常情況下，runbook 是供代理程式參考的操作知識；這項漏洞卻讓外部攻擊者能在沒有登入的情況下更新它。
- 攻擊者把刻意設計的文字寫入 runbook 向量庫。
- 日後遇到相關查詢時，檢索機制選中這段內容。
- 模型把被汙染的資料放進推理上下文，未能確實區分「資料」與「指令」。
- 惡意內容影響工具選擇或參數；若代理程式擁有付款、查詢或匯出權限，風險便從錯誤回答擴大為真實操作。
合理推論：真正危險的不是向量本身，而是信任被連續傳遞：寫入端沒有驗證、檢索端信任內容、模型可決定工具呼叫，而執行端又缺少獨立授權。只要最後一層仍有嚴格的交易簽核、參數白名單或最小權限，惡意文字不必然能完成付款。因此，「可引導工具」與「已成功竊款」是兩件不同的事。
MCP 也不是漏洞本身；它提供模型與工具溝通的介面。官方 MCP Apps 文件說明，敏感工具可採伺服器層級或逐工具授權，並在 HTTP 邊界拒絕未授權呼叫：https://apps.extensions.modelcontextprotocol.io/api/documents/authorization.html。換句話說，模型決定「想呼叫什麼」，不應等同於系統自動批准「可以做什麼」。
為何現在值得注意
這個案例的重要性不在 CVSS 是否最高，而在它把間接提示注入帶進金融交易環境。同一份 IBM 公告還列出多項傳統弱點，包括 CVE-2026-18162 的 new Function 程式碼注入與 CVE-2026-18163 的不安全反序列化，兩者分數均為 9.8。這表示維運團隊不能只做「AI 安全」專案，也不能只依傳統弱點掃描結果排序；代理系統會把應用程式、資料管線、身分權限與工具執行面串成同一條風險鏈。
作者觀點：RAG 常被當成降低幻覺的可靠性設計，但一旦資料來源可被攻擊者控制，「更相信檢索內容」反而會提高攻擊成功率。企業真正需要管理的是資料來源的身分、版本、完整性與用途，而不只是模型輸出的語氣是否合理。
實際影響與修補優先序
直接處置是清查受影響版本並升級至 4.0.11.0。由於 IBM 沒有提供 workaround，網路隔離或暫停相關端點只能算降低暴露面的補強，不能取代修補。修補後也不宜假設既有向量庫自然恢復可信：若攻擊者先前已寫入內容，程式更新未必會自動移除汙染資料。
OWASP 的 RAG Security Cheat Sheet 建議限制向量索引寫入、保存每次新增與修改的身分及時間、建立可回復快照，並以來源、文件雜湊與不可竄改紀錄維持資料血緣；對工具輸出則應使用動作與參數白名單、結構化格式驗證，且不得直接執行模型輸出。參考：https://cheatsheetseries.owasp.org/cheatsheets/RAG_Security_Cheat_Sheet.html。
容易忽略的限制
目前公開資料是一份供應商弱點公告，不是完整鑑識報告。公告沒有提供概念驗證程式、實際受害者、遭利用規模，也沒有證明所有部署都把 AI agent 連到相同的付款工具。Forkast 所稱同批 47 項漏洞，也不能直接推導為已有人把它們串成完整攻擊鏈。
此外，CVSS 7.3 描述的是通用技術嚴重度，不包含個別機構的網路分區、工具權限、付款限額與人工複核。若 agent 只能讀取非敏感資料，實際衝擊可能較低；若它能直接發動高額交易，單靠基礎分數排序則可能低估業務風險。
對台灣金融與企業使用者的意義
現有來源不足以證明台灣有多少 FTM 受影響部署，因此不宜渲染成本地災情。但對正把內規、客服知識、維運手冊或交易流程接上 AI agent 的銀行、金控與大型企業，這是一個可直接套用的架構警訊：能寫入知識庫的人，可能間接左右代理程式的下一個動作。
實務上，付款、受款人變更、資料大量匯出與權限調整等高風險操作，應在模型之外重新驗證使用者身分、交易內容與授權層級；必要時要求人工核准。向量庫則應區分租戶與資料等級，只有經驗證的匯入管線能寫入，並保留從來源文件、切塊、嵌入到工具呼叫的完整稽核軌跡。
後續觀察指標
- 受影響單位是否完成 4.0.11.0 升級，並清查歷史 runbook upsert 紀錄。
- IBM 是否更新公告、擴大版本範圍，或發布入侵指標與額外清理程序。
- 是否出現公開概念驗證、實際利用證據或與其他 FTM 弱點串接的攻擊鏈。
- 組織能否證明每次 MCP 工具呼叫均有身分、來源內容、參數、授權結果與執行結果可供追溯。
- 高風險工具是否真正落實最小權限與交易前核准，而非只依賴提示詞要求模型「小心行事」。