AI 基礎設施的風險，已不只是「模型會不會被提示注入」。Wiz Threat Research 公布 90 天蜜罐遙測，稱其在 LiteLLM、Flowise、LangChain、Langflow、ChromaDB、Ollama 等服務上，觀察到持續攻擊活動：從 MCP 閘道繞過認證、利用測試端點執行任意指令，到入侵後直接搜尋模型金鑰。這批紀錄的價值，在於攻擊者已把 AI 軟體視為可掃描、可變現的雲端入口，而非等待未來才可能出現的概念性風險。原始研究見 https://www.wiz.io/blog/ai-infrastructure-honeypot。
三條攻擊鏈，跨越了三種安全邊界
來源事實：第一條路徑發生在 LiteLLM 的 MCP 功能。CVE-2026-59822 是 OAuth2 轉送備援邏輯的認證繞過：金鑰驗證失敗後，系統可能建立一個沒有約束的空白授權物件，使偽造 Bearer token 也能列舉或呼叫已設定的 MCP 工具。LiteLLM 的第一方安全公告確認，受影響版本為 1.84.0 以前，1.84.0 起修補；無法立即升級時，官方建議封鎖相關 MCP 路由。公告見 https://github.com/BerriAI/litellm/security/advisories/GHSA-7488-6r32-c95q。
另一個漏洞 CVE-2026-42271 位於 MCP stdio 伺服器的連線與工具清單測試端點。端點接受包含 command、args 與 env 的設定，測試時會在 LiteLLM 主機上產生子行程。GitHub Advisory Database 確認，1.74.2 至 1.83.6 受影響，1.83.7 修補，漏洞本身原先仍要求有效的代理 API 金鑰，但未檢查使用者角色，低權限內部金鑰也可能執行任意指令。查證資料見 https://github.com/advisories/GHSA-v4p8-mg3p-g94g。
Wiz 蜜罐捕捉到的實際載荷會下載加密貨幣挖礦程式、使其脫離原行程運作，再刪除暫存目錄；同時回傳看似正常的 MCP 握手，讓「測試成功」成為掩護。這不是 MCP 規格必然導致的結果，而是產品把外部可控設定交給 subprocess 執行所形成的實作漏洞。若再與其他認證或 Host header 缺陷串接，前置條件才可能進一步下降；不能把單一 CVE 直接描述成所有部署皆可匿名接管。
來源事實：第二條路徑是盲提示注入。研究人員在 LangChain、Flowise、OpenWebUI 與 Node-RED 蜜罐看到代理程式產生對攻擊者網域的 DNS 查詢。這類回呼讓攻擊者即使看不到模型回答，也能確認代理是否依指示呼叫 shell，接著再從外部網站取得編碼後的命令並部署 XMRig。需要特別保留的界線是：Wiz 沒有捕捉到原始自然語言提示；其文章展示的提示內容，是依行程樹與已知技術重建，並非封包中的逐字證據。
第三條路徑出現在入侵後。攻擊者不只翻找一般 SSH 或雲端憑證，也查詢 LiteLLM 執行中 Python 模組的狀態，企圖取得 proxy master key，並列舉特定設定檔路徑與可用的後端模型。另有惡意程式被放進看似正常的 AI 工具目錄。這顯示攻擊工具已開始理解 AI 軟體的檔案結構、程序名稱與憑證位置。
真正的商業邏輯：攻下一個閘道，取得多個下游權限
合理推論：AI 閘道的吸引力不只在算力。企業通常透過單一代理連接多家模型供應商，再讓代理存取資料庫、程式碼儲存庫、協作平台或內部 API。這使它同時集中模型額度、服務憑證、雲端身分與內網可達性。挖礦只是最容易觀測的變現方式；若取得高權限金鑰，潛在影響還可能包含推論額度遭濫用、敏感資料被讀取，以及沿 MCP 工具向下游移動。
MCP 官方規格也說明一項容易誤讀的設計現實：協定提供 HTTP 傳輸的授權框架，但是否啟用授權屬於實作選項；一旦採用，伺服器應驗證 token 的有效性與目標資源，無效或過期 token 應回覆 401。這表示「支援 MCP」不等於「已安全部署 MCP」，驗證、權限範圍與網路邊界仍由產品及部署者落實。規格見 https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization。
為何現在值得注意
作者觀點：關鍵轉折不是攻擊手法全部嶄新，而是傳統漏洞、代理式操作與 AI 專屬偵察已被串成連續流程。企業導入 AI 的速度往往快於資產登錄：開發者可能先架設測試閘道、工作流或 MCP server，再補上認證與監控。攻擊者卻不需要知道該系統是否正式上線，只需掃到公開服務、辨識版本並嘗試現成載荷。
證據的限制不能省略
- 蜜罐能證明特定行為確實出現，卻不能代表全球受害比例；原文沒有提供蜜罐數量、地域分布、成功率或受害企業數。
- 部分活動可能是大量自動掃描，不等於每次嘗試都成功，也不能僅憑同類載荷判定背後為同一組織。
- Wiz 是資安服務供應商，研究同時連結自家產品；技術細節可由公告交叉驗證，但市場規模與防禦成效仍應分開評估。
- 網路 IOC 與檔案路徑容易更換。只封鎖單一 IP、網域或檔名，無法替代版本修補、權限縮減與執行期偵測。
對台灣企業的實際意義
台灣企業常以概念驗證方式導入生成式 AI，並由資訊、研發、資料或個別事業單位各自架設服務。最急迫的工作不是再買一層「AI 防火牆」，而是先找出所有對外的 LiteLLM、Flowise、Langflow、Ollama 與 MCP 端點，確認版本、負責人、認證方式及可連接的下游系統。CVE-2026-42271 至少應升級至 1.83.7，CVE-2026-59822 則應升級至 1.84.0 以上；若無法立即升級，先由反向代理封鎖測試與 MCP 路由。
其次，應把模型供應商金鑰、代理 master key 與雲端 IAM 拆分，限制用途、額度、來源與存取範圍；MCP 工具也不應沿用管理員權限。出站 DNS 與 HTTP 連線可採允許清單，降低盲提示注入回呼及下載第二階段載荷的能力。監控面則應關注「AI 服務產生 shell、下載器或挖礦程序」的父子行程關係，而不只掃描磁碟檔案。
後續觀察指標
- 公開 AI／MCP 端點數量，以及其中未啟用認證或版本落後的比例。
- 模型金鑰是否分環境、可輪替、設有用量上限，並能追溯到實際工作負載。
- AI 服務衍生 shell、異常 DNS 回呼、外部貼文網站下載與持續高 CPU 的告警量。
- 新修補程式發布到公開端點完成更新的時間差，以及 MCP 工具權限是否定期複核。
這份 90 天遙測最重要的訊號，是 AI 基礎設施已進入攻擊者的日常作業流程。防守重點也因此不該停在模型輸出是否安全，而要回到更完整的問題：誰能向代理下指令、代理能呼叫什麼、主機保存哪些憑證，以及一旦入口失守，攻擊者還能走多遠。