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上。

摘要

MCP伺服器是代理生態系中成長最快的整合介面，同時也是最缺乏稽核的。漏洞資料庫已收錄50筆紀錄：13個重大、32個高危。輸入驗證失敗與提示注入佔了50筆中的30筆。本週單日內就有三個不同MCP伺服器被揭露出三個SSRF漏洞。³ 模式顯而易見：社群推出MCP伺服器的速度，遠超過審查它們的速度。

重點摘要

• Claude Code使用者： 每個連接的MCP伺服器都代表您正在延伸的信任邊界。立即執行claude mcp list，稽核已連接的項目。若您正在使用數月前安裝的社群MCP伺服器，請確認它們是否已修補。
• 工具鏈開發者： PreToolUse hooks是MCP工具呼叫抵達未經稽核伺服器前的最後一道防線。建議設置hooks來驗證MCP工具輸入——尤其是接受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位安全研究員貢獻了研究結果。受影響的伺服器包括GitHub自家的Git MCP伺服器、官方MCP Inspector、Microsoft MarkItDown、GitLab Kanban、Figma、Jira、Grafana、Neo4j、Kubernetes，以及20多個社群建置的伺服器。¹

最具警示意義的是調查結果：2,614個MCP實作中有82%存在易受路徑穿越攻擊的檔案操作漏洞。² 每五個MCP伺服器中就有四個會讓攻擊者讀取不該存取的檔案。

五種攻擊模式

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

1. 工具投毒。 在MCP工具描述中嵌入惡意指令。代理讀取描述後信任其內容，並使用自身的授權工具執行隱藏指令。被投毒的工具從未執行——代理的合法工具代為完成攻擊。我們在部署與防禦悖論中探討過此模式：信任是傳遞的，稽核卻不是。

2. 透過外部資料的提示注入。 從GitHub issues、Slack訊息、電子郵件或網頁抓取內容的MCP伺服器，會將攻擊者控制的文字帶入代理的上下文中。注入的目標不是MCP伺服器——而是讀取伺服器輸出的代理。靜默外洩攻擊面是其通用案例；MCP伺服器則是最常見的攻擊向量。

3. 初次核准後的信任繞過。 Claude Code在首次連接MCP伺服器時會要求您核准。此後，工具定義可在不同工作階段之間變更，且並非所有情況都會重新提示——安裝時安全的伺服器，在更新後可能表現迥異。重新驗證的空隙是結構性的：協議不要求對工具描述進行加密簽章。²

4. 供應鏈入侵。 被植入後門的MCP伺服器發布到套件庫中，包括冒充合法伺服器的套件。與我們在供應鏈即攻擊面中記錄的相同供應鏈模式，應用於MCP生態系。

5. 跨租戶暴露。 在共享託管環境中，多個MCP伺服器可在執行前攔截彼此的函式呼叫。⁴ 從外部看似堅固的隔離邊界，在多個伺服器共享行程或容器時便會瓦解。

SSRF模式

本週一次掃描中，在三個不同的MCP伺服器中發現了三個SSRF漏洞：³

• n8n-mcp： 透過實例主機注入的經驗證SSRF
• mcp-from-openapi： 透過OpenAPI規格中的$ref值進行SSRF——含有內部URL的惡意規格會在伺服器初始化時觸發資源抓取
• stata-mcp： 對使用者提供的URL驗證不足

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

步驟1。 攻擊者發布一個看似合法的MCP伺服器，用於包裝外部API。該伺服器使用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容器中。請求從受信任的來源發往AWS中繼資料端點。

步驟4。 中繼資料端點回傳臨時IAM憑證：存取金鑰、密鑰、工作階段權杖。

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

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

Microsoft於2026年3月修補了一個重大的Azure MCP SSRF漏洞（CVE-2026-26118）——同樣的模式應用於Azure：一個高嚴重性的權限提升漏洞，可竊取身份驗證權杖並取得Azure資源的未授權存取。⁵

應對措施

稽核已連接的伺服器。 執行claude mcp list並檢視每個伺服器。將每個伺服器與Vulnerable MCP Project資料庫進行比對。¹ 移除未在使用的伺服器。

鎖定伺服器版本。 若您從npm或pip安裝MCP伺服器，請鎖定版本。不要自動更新。升級前先檢視變更紀錄——信任繞過模式意味著更新可在未經重新核准的情況下變更工具定義。

新增輸入驗證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

考慮傳輸層隔離。 HTTP MCP伺服器在自己的行程中運行，具有明確的網路邊界。Stdio伺服器則共享代理的行程上下文。兩種傳輸方式都不是天生安全的——更關鍵的因素在於伺服器是否能存取憑證、內部網路或敏感檔案路徑。選擇符合您威脅模型所需隔離邊界的傳輸方式。

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

MCP生態系正在快速成長——3,000多個已索引的伺服器，每月下載量超過1億次。⁶ 安全態勢卻未同步提升。一個一年前根本不存在的資料庫中已有50個漏洞。問題不在協議本身，而在實作。

資料來源

常見問題

Claude Code內建的MCP伺服器是否受影響？

漏洞主要影響社群建置及第三方MCP伺服器，而非Claude Code的核心MCP基礎設施。不過，官方MCP Inspector工具確實曾存在RCE漏洞，因此「官方」並不等同「免疫」。

是否應該停止使用MCP伺服器？

不需要。MCP是強大的整合層。但應將每個MCP伺服器視為信任邊界。稽核已連接的項目、鎖定版本，並為接受URL、檔案路徑或shell命令的伺服器新增輸入驗證hooks。

如何檢查我的MCP伺服器是否存在漏洞？

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