MCP 伺服器是新的攻擊面

Model Context Protocol 現在有了安全資料庫。裡面共有 50 條紀錄。¹

60 天內歸檔了 30 個 CVE。在調查的 2,614 個 MCP 實作中，有 82% 存在容易遭受路徑遍歷的檔案操作漏洞。38% 至 41% 的伺服器完全沒有驗證機制。² 官方的 MCP Inspector 工具——也就是開發者用來除錯 MCP 伺服器的那個工具——存在 RCE 漏洞。廣泛使用的 mcp-remote 套件則有 OS 指令注入的錯誤。¹

這不是理論上的攻擊面。這些是真實套件中的真實 CVE，而真實的開發者此刻正把它們連接到 Claude Code、Codex CLI 和 Cursor。本文以協定層級的威脅分析延伸 agent security 的討論範疇。

TL;DR

MCP 伺服器是代理生態系中成長最快的整合面，也是稽核最少的一塊。漏洞資料庫有 50 條紀錄：13 個嚴重等級，32 個高等級。輸入驗證失敗與提示注入就佔了 50 個之中的 30 個。本週單日之內，就有三個不同 MCP 伺服器爆出 SSRF 漏洞。³ 模式十分清楚：社群發布 MCP 伺服器的速度，遠快於審查它們的速度。

關鍵要點

• Claude Code 使用者： 每一個您連接的 MCP 伺服器，都是您所延伸的信任邊界。立刻執行 claude mcp list，稽核目前連接了什麼。如果您正在執行數月前安裝的社群 MCP 伺服器，請確認它們是否已經修補。
• 框架建構者： 您的 PreToolUse hooks 是 MCP 工具呼叫抵達未稽核伺服器之前的最後一道防線。不妨考慮在執行前驗證 MCP 工具輸入的 hooks，尤其是針對那些接受 URL、檔案路徑或 shell 指令的伺服器。
• MCP 伺服器作者： MCP 規格寫著「SHOULD always be a human in the loop」。請將其視為 MUST。驗證所有輸入。絕對不要透過字串插補將使用者控制的字串傳入 shell 指令。絕對不要未經 URL 驗證就信任 OpenAPI 規格中的 $ref 值。

數字

Vulnerable MCP Project 維護著一份已記錄 MCP 安全問題的資料庫。¹ 目前狀態如下：

嚴重度： 13 個嚴重等級，32 個高等級，5 個中等級。¹ 共有 32 位安全研究員貢獻了發現。受影響的伺服器包括 Anthropic 自家的 Git MCP 伺服器、官方 MCP Inspector、Microsoft MarkItDown、GitHub Kanban、Figma、Jira、Grafana、Neo4j、Kubernetes，以及 20 多個社群建置的伺服器。¹

調查結果中最具殺傷力的一項是：2,614 個 MCP 實作中有 82% 存在容易遭受路徑遍歷的檔案操作漏洞。² 每五個 MCP 伺服器中就有四個會讓攻擊者讀取本不該存取的檔案。

五種攻擊模式

這 60 天的 CVE 浪潮揭露了五種反覆出現的模式：²

1. 工具下毒。 在 MCP 工具描述中嵌入惡意指令。代理讀取描述、信任描述，接著使用自己獲授權的工具執行那些隱藏指令。被下毒的工具本身從未執行——代理的合法工具才是實際執行攻擊的角色。我們在 deploy-and-defend paradox 中已說明過這種模式：信任是遞移的，稽核卻不是。

2. 透過外部資料進行提示注入。 從 GitHub issues、Slack 訊息、電子郵件或網頁抓取內容的 MCP 伺服器，會把攻擊者可控的文字帶入代理的上下文。注入目標不是 MCP 伺服器，而是正在讀取該伺服器輸出的代理。silent egress attack surface 是通用情境；而 MCP 伺服器是最常見的載體。

3. 初次核准後的信任繞過。 Claude Code 會請您在首次使用時核准 MCP 伺服器。此後，工具定義可能在不同 session 之間變化，而並非所有情況都會重新詢問。安裝時安全的伺服器，在更新時可能行為完全不同。這個重新驗證的缺口是結構性的：協定並未要求對工具描述進行加密簽章。²

4. 供應鏈入侵。 被植入後門並發布至登錄表的 MCP 伺服器，包含偽裝成合法伺服器的套件。這與我們在 the supply chain is the attack surface 中記錄的供應鏈模式相同，只是套用到 MCP 生態系上。

5. 跨租戶曝險。 在共享主機環境中，多個 MCP 伺服器可以在執行前攔截彼此的函式呼叫。⁴ 從外部看似穩固的隔離邊界，在多個伺服器共用同一個 process 或 container 時會失守。

SSRF 模式

本週單次掃描中，三個不同 MCP 伺服器爆出 SSRF 漏洞：³

• n8n-mcp： 透過 instance host 注入造成的已驗證 SSRF
• mcp-from-openapi： 透過 OpenAPI 規格中的 $ref 值造成 SSRF。帶有內部 URL 的惡意規格會導致伺服器在初始化期間擷取那些資源
• stata-mcp： 對使用者提供的 URL 驗證不足

MCP 伺服器中的 SSRF 特別危險，因為伺服器通常擁有代理所沒有的網路存取權限。以下是單一份惡意 OpenAPI 規格如何演變為憑證竊取：

步驟 1。 攻擊者發布一個看似合法、包裝外部 API 的 MCP 伺服器。該伺服器使用 mcp-from-openapi 依 OpenAPI 規格產生工具。

步驟 2。 OpenAPI 規格中有一個指向內部位址的 $ref：

components:
  schemas:
    Config:
      $ref: "http://169.254.169.254/latest/meta-data/iam/security-credentials/role-name"

步驟 3。 在 initialize() 期間，MCP 伺服器透過擷取該 URL 來解析 $ref。伺服器運行在您的基礎設施上：在您的 VPC 之中、您的筆電上，或 CI container 裡。該請求從一個受信任的來源送往 AWS metadata 端點。

步驟 4。 metadata 端點回傳臨時 IAM 憑證：access key、secret key、session token。

步驟 5。 現在伺服器握有您的雲端憑證。它可以把憑證藏在工具回應中外洩、記錄到外部端點，或直接使用。

代理從未做出任何惡意行為。使用者核准了 MCP 伺服器。OpenAPI 規格看起來正常。$ref 解析發生在函式庫層級，位於任何人會審查的層級之下。SSRF 把 MCP 伺服器的網路位置轉換成了攻擊者的網路位置。

Microsoft 已於 2026 年 3 月修補了一個嚴重等級的 Azure MCP SSRF（CVE-2026-26118）。同樣的模式也套用到 Azure 上：一個高等級的權限提升漏洞，可能竊取驗證 token 並獲得對 Azure 資源的未授權存取。⁵

應該怎麼做

稽核已連接的伺服器。 執行 claude mcp list 並檢視每一個伺服器。將每一個都與 Vulnerable MCP Project 資料庫對照。¹ 移除目前未積極使用的伺服器。

固定伺服器版本。 如果您從 npm 或 pip 安裝 MCP 伺服器，請固定版本。不要自動更新。升級前先檢視 changelog。信任繞過模式意味著一次更新就可能在未重新核准的情況下變更工具定義。

加入輸入驗證 hooks。 在 MCP 工具呼叫上套用 PreToolUse hook，可在輸入抵達伺服器之前先進行驗證：

#!/bin/bash
# .claude/hooks/validate-mcp-input.sh
INPUT_JSON=$(cat)
TOOL_NAME=$(echo "$INPUT_JSON" | jq -r '.tool_name // empty')

# Block MCP tools that accept URLs from passing internal addresses
if echo "$TOOL_NAME" | grep -q "^mcp__"; then
  TOOL_INPUT=$(echo "$INPUT_JSON" | jq -r '.tool_input | tostring')
  if echo "$TOOL_INPUT" | grep -qiE '(169\.254\.|10\.|172\.(1[6-9]|2|3[01])\.|192\.168\.|localhost|127\.0\.0\.1|metadata\.google|169\.254\.169\.254)'; then
    echo "Blocked: MCP tool input contains internal/metadata address" >&2
    exit 2
  fi
fi
exit 0

考慮傳輸隔離。 runtime defense patterns for tool-augmented agents 在此可直接適用：每一個 MCP 伺服器都是代理會呼叫的工具，防禦架構必須考慮工具遭到入侵的情境。HTTP MCP 伺服器在自己的 process 中執行，具有明確的網路邊界。Stdio 伺服器則與代理共用 process 上下文。兩種傳輸方式本質上都不是安全的。更關鍵的因素在於伺服器是否能存取憑證、內部網路或敏感的檔案路徑。請選擇能符合您威脅模型所需隔離邊界的傳輸方式。

關注資料庫。 位於 vulnerablemcp.info 的 Vulnerable MCP Project 是最接近 MCP 生態系 CVE 追蹤器的存在。安裝新伺服器前請先查閱。

MCP 生態系正快速成長：收錄了 3,000 多個伺服器，每月下載量達 1 億次。⁶ 安全態勢卻沒有跟上。一個一年前還不存在的資料庫，如今有五十個漏洞。問題不在協定本身，而在實作。正如我在 your agent has a middleman 中所記錄的，代理工具鏈中的每一個中介者，都是多數開發者從未稽核過的攔截機會。

資料來源

常見問題

Claude Code 內建的 MCP 伺服器會受影響嗎？

這些漏洞主要影響社群建置與第三方的 MCP 伺服器，而非核心的 Claude Code MCP 基礎設施。不過官方的 MCP Inspector 工具確實有過 RCE 漏洞，所以「官方」並不等於「免疫」。

我應該停止使用 MCP 伺服器嗎？

不用。MCP 是強大的整合層。但請把每一個 MCP 伺服器都視為信任邊界。稽核您連接的伺服器、固定版本，並為接受 URL、檔案路徑或 shell 指令的伺服器加上輸入驗證 hooks。

我要如何確認自己的 MCP 伺服器是否有漏洞？

執行 claude mcp list 查看已連接的伺服器。將每一個與 Vulnerable MCP Project 資料庫對照。檢視該伺服器的 GitHub 儲存庫中是否有近期的安全公告。