MCP Security: 5 Real CVE Classes Every Agent Team Should Know

2026 年有五個不同的 MCP 漏洞類別走到公開 CVE 或已確認事故,每一類都對應到 agent 連接 Model Context Protocol 伺服器方式上的不同破口。它們是:網路綁定 RCE(MCPJam Inspector CVE-2026-23744)、SSRF 憑證竊取(Azure MCP Server CVE-2026-26118)、設定與 hook 濫用(Claude Code CVE-2025-59536 與 CVE-2026-21852)、可信伺服器供應鏈污染(postmark-mcp),以及 tool description 注入。本文逐一說明每一類、背後真正的 CVE,以及確定性偵測如何在伺服器執行前就攔下這個 pattern。

我經營 ATR,一個獨立、開放、MIT 授權的偵測標準,PanGuard 建構在它之上並負責營運。這個關係就像 Sigma 或 CVE 之於營運它的廠商。以下不是理論。每一個 CVE 都可驗證,每一項偵測主張都對應到一個接近 690 條規則(2026 年 7 月)的 corpus。

第一類:網路綁定 RCE(MCPJam Inspector CVE-2026-23744)

MCPJam Inspector 預設把介面綁在 0.0.0.0,意思是它監聽每一個網路介面,而不是只監聽 localhost。在 v1.4.3 之前的每一個版本,只要一個來自網路上任何可達位置的精心構造 HTTP 請求,就能變成遠端程式碼執行。這是把最古老的錯誤套用到一個全新的工具類別。一個原本只用於本機檢查的開發工具,悄悄變成了對外暴露的 RCE 面。偵測在掃描階段就攔下這一類:在伺服器啟動之前,就在 MCP 伺服器程式碼與 manifest 裡標記 0.0.0.0 與 wildcard 綁定設定。pga scan <target> 會在你安裝前檢查伺服器,所以這個錯誤設定在審查時就浮現,而不是在事故時。

第二類:SSRF 憑證竊取(Azure MCP Server CVE-2026-26118)

Azure MCP Server CVE-2026-26118 是一個 server-side request forgery 漏洞。攻擊者誘使伺服器對雲端 metadata endpoint 發出請求,而該 endpoint 會回傳一個 managed-identity token。這個 token 隨後就取得了 agent 本不該碰到的 Azure 資源存取權。SSRF 的危險正在於請求來自可信的伺服器,因此繼承了伺服器的身分。偵測攔下這一類的方式,是比對抓取內部 metadata 位址的 tool call,以及觸及 link-local 或 metadata IP 範圍的請求 pattern。規則觸發的是動作,不是描述裡的字串,所以它經得起改寫。

第三類:設定與 hook 濫用(Claude Code CVE-2025-59536 + CVE-2026-21852)

兩個針對 Claude Code 的 CVE,CVE-2025-59536 與 CVE-2026-21852,利用 hooks 系統與 MCP 設定達成任意 shell 執行與 API key 竊取。Hooks 與設定檔是可執行面。當一個不可信的 repository 或被污染的設定可以注入 hook 時,光是打開一個專案就足以執行攻擊者的程式碼並外洩 key。這是多數 agent 團隊低估的一類,因為他們把設定當成惰性資料。偵測攔下它的方式,是掃描 .claude/ 設定、settings、hooks 與 MCP 伺服器定義裡的注入 pattern,並把「一個會生出 shell 的 hook」當成第一級偵測目標,而不是無害功能。

第四類:可信伺服器供應鏈污染(postmark-mcp)

postmark-mcp 是一個可信的 MCP 伺服器,它在被發現前的 15 個版本裡,每天靜靜地 BCC 了 3,000 到 15,000 封郵件。沒有人劫持這個伺服器。是伺服器本身帶著惡意行為,包在一個團隊早已信任的套件裡出貨。這是最純粹的 agentic 供應鏈風險:攻擊搭乘的是你對一個相依套件所給出的信任。偵測攔下這一類的方式,是掃描伺服器的行為,而不是它的名聲。一個會加上隱藏 BCC 收件者或外洩訊息內容的工具,無論發布者看起來多可靠,都是一個可偵測的動作 pattern。這也是為什麼 runtime 偵測重要。Guard 監看伺服器安裝後實際採取的動作。

第五類:tool description 注入

第五類是 tool description 注入,MCP 伺服器把對抗性指令藏進它所暴露的某個工具的 description 裡。當 agent 讀取工具清單時,被污染的 description 就成為 prompt 的一部分,可以改寫 agent 的目標。這直接對應到 OWASP Agentic Top 10 的 ASI01 Agent Goal Hijack 與 ASI02 Tool Misuse and Exploitation。偵測攔下這一類的方式,是把 tool description 當成不可信輸入,並比對其中的注入標記,就像 prompt-injection 規則對待使用者文字一樣。因為規則把 description 當成資料來讀,被污染的工具沒辦法只靠措辭客氣就把指令偷渡過去。

偵測如何攔下這五類

貫穿的主線是:這五類裡有四類講的是動作與設定,而不是使用者訊息裡的某一句話。這正是確定性的 Layer 1 規則發揮價值的地方。一旦一個攻擊被理解,它就被寫成一條規則,然後為所有人以毫秒級執行。新攻擊到規則大約要一小時。

corpus 背後的數字,一律以 Layer 1 確定性規則的脈絡引用,絕不當成單一混合引擎分數:在 498 個真實樣本的 SKILL.md corpus 上,100% recall、97% precision、0.2% 誤報。在 NVIDIA garak 的 650 個 in-the-wild jailbreak 樣本上,97.2% recall。在自建的 850 個 PINT 格式樣本上,99.7% precision、63.6% recall。在 HackAPrompt(4,780 個樣本)上,69.6% recall 對比 28.6% 基線,100% precision。65,000 個樣本的 benign gate 上的誤報是分 lane 的:enforce lane 約 0.24%,預設的 hunt lane 約 9%。沒有單一的混合 FP 數字,我也不會假裝有。

作為規模脈絡,我掃描了六個公開 registry 上的 96,096 個 AI agent skill,確認其中 751 個為惡意。上述五類 CVE 不是邊角案例。一旦 agent 開始連接自己沒寫的 MCP 伺服器,這就是威脅面的形狀。

FAQ

最被低估的 MCP 漏洞類別是哪一個?

設定與 hook 濫用。針對 Claude Code 的 CVE-2025-59536 與 CVE-2026-21852 顯示,打開一個帶有被污染 hook 或 MCP 設定的專案就足以執行攻擊者程式碼,因為團隊把可執行的設定當成惰性資料。

postmark-mcp 事故為何這麼久沒被發現?

因為它是可信伺服器。它在被發現前每天 BCC 3,000 到 15,000 封郵件,持續 15 個版本。基於名聲的信任攔不下藏在你早已信任套件裡的惡意動作,所以行為掃描才重要。

偵測能可靠攔下 tool description 注入嗎?

能,方法是把 tool description 當成不可信輸入,而非可信 metadata。規則把 description 當成資料來比對其中的注入標記,被污染的工具就無法把指令偷渡過去。它對應到 OWASP ASI01 與 ASI02。

ATR 跟 PanGuard 是同一個東西嗎?

不是。ATR 是一個獨立、開放、MIT 授權的偵測標準,獨立治理。PanGuard 是建構在它之上並營運它的免費產品,就像廠商營運 Sigma 或 CVE 一樣。

在安裝任何 MCP 伺服器或 skill 前先掃描它:npm install -g @panguard-ai/panguard && pga up,然後 pga scan <target>。它免費且 MIT 授權,ATR 標準也開放給你閱讀與擴充。