工具即攻擊面：2026 的 MCP 漏洞連環爆與「工具下毒」

快速摘要：2026 上半年，MCP（讓 AI 統一連接外部工具的協議）漏洞連環爆——Anthropic 官方 Git MCP 三個 CVE、影響 7000+ 伺服器的 STDIO 設計缺陷、gemini-mcp-tool 的 CVSS 9.8 命令注入、Claude Code 專案檔的 RCE 與金鑰外洩。共同主題是「工具下毒」與「過寬權限 + 不可信輸入」。文末檢驗 fibon 的可信／不可信 MCP 分層與工具雜湊驗證。

可略過，如果：你的 AI 工具不連任何外部 MCP server。

當「連接工具」變成攻擊面

MCP（Model Context Protocol）是 2024 年底推出的協議，讓 AI 能用統一的方式連接外部工具——就像給 AI 一個標準化的外接插頭。它解決了真實的問題，也因此被大量採用。但 2026 上半年，這個插頭成了戰場。AuthZed 的時間線統計，光是 2026 年 1 到 4 月，研究者就揭露了逾 40 個 MCP 相關 CVE。挑幾個有代表性的：

Anthropic 官方 Git MCP 的三個 CVE（2026-01-20 披露）。 諷刺的是出問題的是官方參考實作 mcp-server-git——開發者被期待直接拿來複製的那個。三個漏洞裡最嚴重的 CVE-2025-68143（CVSS 8.8）讓 git_init 工具接受任意路徑、把系統上任何目錄變成 git repo；CVE-2025-68145（你可能聽過的那個 --repository flag 未驗證）讓後續工具呼叫存取 server 上任何 repository。串起來，再配上 Filesystem MCP，可以組成一條完整的 RCE 鏈。觸發向量是 prompt injection——一個惡意 README、一個被污染的 issue 描述就夠了，攻擊者不需要直接碰你的系統。

影響 7000+ 伺服器的 STDIO 設計缺陷（2026-04-20 披露）。 這個更根本——不是某段程式碼的 bug，而是官方 MCP SDK 內建、跨所有語言的架構決策。STDIO transport 把「配置」直接轉成「命令執行」，沒有 input sanitization。OX Security 的分析產出了 10 個 high/critical CVE、波及 150M+ 下載量，其中包括 zero-click 攻擊：處理攻擊者可控的 HTML 內容時，惡意指令能改掉本地 MCP 配置、自動註冊一個惡意 STDIO server，然後在使用者毫無互動下執行任意命令。Anthropic 的立場是這行為「符合預期」，拒絕改協議架構。

gemini-mcp-tool 的命令注入零日（CVE-2026-0755，CVSS 9.8，2026-01-09 披露）。 這是個非官方開源工具，它的 execAsync 把使用者輸入直接拼進系統命令丟給 shell。Penligent 的分析有一句話值得刻在牆上：PoC 在直接 curl 時成功、在 Claude Desktop 介面失敗——因為 client 端的 safety filter 像 WAF。但他們的結論是：「client 端禮貌的拒絕，不是防禦。」 攻擊者繞過 UI、直接送 raw JSON-RPC 到暴露的 port 就行。

反覆出現的破口：過寬權限 + 不可信輸入

把這些 CVE 攤開，AuthZed 歸納出最反覆出現的破口模式：過寬的憑證權限，結合不可信的工具／上下文輸入。 一個 over-privileged 的 token，加上 LLM context 裡的一段不可信內容（被 prompt injection 操控），就能讓一個合法的 MCP 工具呼叫變成攻擊者的提款機。

另一個 AI-native 的新向量是工具下毒（tool poisoning）：把惡意指令藏在工具的 description／metadata 裡，agent 會把它當成「這個工具能做什麼」的 ground-truth。傳統安全工具根本不會去監控「工具描述」有沒有被偷改——這是 MCP 時代才有的供應鏈面。學術界（arXiv:2603.22489，用 STRIDE/DREAD 對 MCP 做威脅建模）的結論是：tool poisoning 是最普遍、影響最大的 client-side 漏洞。

對 fibon 的意義

MCP 是 fibon 的骨幹之一——三個服務之間、以及對外部工具，全走 MCP 與 gRPC。所以這串漏洞對 fibon 不是隔岸觀火，是直接相關。fibon 在這條線上的設計，有幾處正好對上：

可信／不可信 MCP 分層 + Worker 隔離網路。 fibon 不把所有 MCP 一視同仁。不可信的外部 MCP 由 Worker 中轉，而 Worker 跑在隔離的 Docker 網路（fibon-isolated-net）裡，設計目標明寫「即使被攻破也無法觸及 Gateway 的 API Key 或資料庫」（第 6 章）。上面那些 STDIO 命令注入、reverse shell 的 payload，就算在 fibon 裡被觸發，它落地的地方是一個摸不到金鑰、摸不到 DB 的隔離容器——這正是「過寬權限」破口的反面：預設最小權限、預設不可信。瀏覽器能力也在 2026-05 遷到獨立的 playwright-mcp sidecar（ADR-019），同樣是隔離思路。

工具下毒的對應防線——description 雜湊驗證。 這點正好打在 tool poisoning 上：fibon 的工具註冊表（tool_registry）對每個工具的 description 算雜湊（description_hash），用來偵測竄改——如果一個工具的描述被偷改了，雜湊對不上就會被抓到。這跟 AuthZed 說的「傳統工具不監控 description 變動」恰好相反，fibon 把它變成一個會驗的欄位。此外 Brain 對 Worker／MCP 回傳的所有 tool output 都做 Pydantic schema 驗證加 sanitization，不信任工具吐回來的東西。

這一串 MCP 漏洞最該帶走的觀念，其實跟〈ClawHub 供應鏈攻擊〉那篇是同一個：AI agent 連接的每一個外部工具，都是一段會以 agent 身分執行的「可信指令」。 不管它叫 skill 還是叫 MCP server，本質都是「你授權了一段別人寫的東西，以你的權限行動」。Penligent 那句「client 端的拒絕不是防禦」是這整個主題的鑰匙——安全不能寄望在 LLM 介面會幫你擋，必須蓋在你自己控制的 server 端、用最小權限和隔離把爆炸半徑畫小。fibon 在這條線上蓋好了隔離與雜湊驗證，還欠 MCP 工具的內容審查那一道——標記在這，待補。