返回資料庫
安全與治理

MCP 安全強化清單：1,467 台暴露伺服器以及關閉它們的方法

作者：最後更新：2026年7月26日

Trend Micro 掃描了網際網路，發現 1,467 個 MCP 伺服器裸露在外——沒有認證、沒有加密、任何人都能存取。Practical DevSecOps 發現 2,614 個受調查伺服器中有 82% 存在路徑遍歷漏洞。一個為將 AI 代理接入企業系統而設計的協定在發布時沒有生產安全基線，部署模式也證明了這一點：大多數團隊在加固 MCP 之前就把它暴露到了網際網路。這份清單是本應最先到來的基線——涵蓋傳輸、認證、工具註冊、執行時和稽核的 12 項控制，每一項都能在五分鐘內驗證完畢，確保 MCP 伺服器在承接生產流量之前達標。

關鍵要點

  • 1,467 台 MCP 伺服器公開可存取且零認證零加密 — Trend Micro 修正後的掃描，2026 年 7 月。其中 1,227 台執行 2026-07-28 規範以 12 個月棄用時鐘淘汰的 SSE 傳輸。
  • 2,614 台受調查 MCP 伺服器中 82% 易受路徑遍歷攻擊，僅 8.5% 使用 OAuth — Practical DevSecOps MCP Security Statistics 2026 Report。這些攻擊類別在已部署伺服器中廣泛存在，不是理論性的。
  • 2026 年 7 月官方 MCP Python SDK 中出現 3 個 CVE — CVE-2026-59950（DNS rebinding/CSRF）、CVE-2026-52869（未驗證的工作階段請求）、CVE-2026-52870（開放任務處理器）。參考實作與它支撐的社群伺服器存在同類缺陷。
  • 5 台 MCP 伺服器連接 1 個 agent 時攻擊成功率达 78.3% — Palo Alto Networks Unit 42。五台伺服器是典型部署，不是大規模部署。OX Security 識別出一個影響 150M+ 下載量的架構級 RCE，Cloud Security Alliance 將 MCP 安全歸類為系統性設計缺陷問題。
  • MCP 2026-07-28 規範於 2026 年 7 月 28 日正式發布 — 四個 Tier 1 SDK（TypeScript、Python、Go、C#）在發布日均支援新的無狀態核心，SSE 傳輸有 12 個月棄用策略。遷移和強化是同一項工作。

通過這份清單 12 項控制的生產 MCP 部署不是不可入侵的——沒有任何系統是——但它不再屬於 Trend Micro 發現的、Practical DevSecOps 掃描的、或 7 月 CVE 波捕獲的那批伺服器。清單將每項控制對映到它所解決的 OWASP MCP Top 10 類別、它所預防的 CVE 或暴露、以及操作員可在五分鐘內執行的驗證步驟。Microsoft Agent Governance Toolkit——首個具備 10/10 OWASP MCP Top 10 覆蓋的超大規模廠商開源治理執行時——是參考實作。本文是營運層面的補充：一份可掃描的強化審查，面向準備將 MCP 伺服器暴露於生產流量的工程負責人或平台負責人。

攻擊面，用數字說話

OWASP MCP Top 10（Beta Release v0.1，Phase 3 of 5）編目了 MCP 啟用系統全生命週期的 10 個命名風險類別。背後的數字將「治理是好實踐」變成「治理是生產門控」：

  • 1,467 台暴露伺服器 — Trend Micro 修正後的掃描 發現 1,467 台公開可存取的 MCP 伺服器，無認證無加密，從初始計數 492 上升。1,227 台執行棄用的 SSE 傳輸。至少三台透過 progress_note 工具暴露患者醫療記錄。execute_sql 工具出現在 70 台主機上。
  • 82% 路徑遍歷暴露 — Practical DevSecOps 在 2,614 台受調查伺服器中測得 82% 路徑遍歷漏洞和 8.5% OAuth 採用率。97M+ 月度 MCP 下載量意味著暴露隨採用規模增長。
  • 150M+ 下載量受架構級 RCE 影響 — OX Security 將 STDIO 命令注入根因定性為架構級缺陷，而非孤立的 CVE。Cloud Security Alliance 將其歸類為 AI agent 基礎設施中的系統性設計缺陷問題。
  • 2026 年 7 月 SDK 中 3 個 CVE — CVE-2026-59950（缺少 Host/Origin 驗證、DNS rebinding/CSRF）、CVE-2026-52869（未驗證的工作階段請求）、CVE-2026-52870（開放任務處理器）。官方 Python SDK——每個 Python MCP 伺服器繼承的參考實作——與它支撐的社群伺服器存在同類缺陷。
  • 最終規範中的 3 個新攻擊面 — backslash.security 識別出 2026-07-28 規範中無狀態重新設計引入的三個新攻擊面。新能力創造新入口點，安全社群仍在繪製中。

cataam.com 分析 精準概括了 MCP 安全現狀：「MCP 安全大致處於十五年前 Web 安全的位置——攻擊手法是舊的，只是目標是新的。」下面的強化清單是將 Web 安全從 82% 路徑遍歷暴露提升到生產系統預期通過的基線的控制集合。同樣的控制在此適用。

12 項強化控制

清單圍繞五個層級組織，對映到 OWASP MCP Top 10 和 MCP 2026-07-28 規範變更：

MCP Security Hardening Checklist 12 controls across 5 layers — maps to OWASP MCP Top 10 1 Transport & Network Spec 2026-07-28 + OWASP MCP07 2 controls CONTROL 1 SSE to Streamable HTTP migration 12-month deprecation — 1,227 servers affected CONTROL 2 Network isolation & origin validation CVE-2026-59950 — DNS rebinding defense 2 Authentication & Identity OAuth 2.1 + OIDC — spec mandate 2 controls CONTROL 3 OAuth 2.1 + OIDC enforcement RFC 8707 + RFC 9207 — 8.5% baseline CONTROL 4 Agent identity separation NIST OAuth 2.0 + SPIFFE/SPIRE 3 Tool Registration & Supply Chain OWASP MCP03 + MCP04 3 controls CONTROL 5 Tool poisoning scan MCP03 — injection + typosquatting CONTROL 6 Signed provenance MCP04 — AIBOM inventory CONTROL 7 STDIO hardening 150M+ downloads — OX Security 4 Runtime & Execution OWASP MCP05 + MCP06 + MCP10 3 controls CONTROL 8 Rate limiting Per-agent, per-tool, per-window CONTROL 9 Context boundary MCP10 — scoped per tool, no oversharing CONTROL 10 Kill-switch per module Feature-flag disable, no redeploy 5 Audit & Telemetry OWASP MCP08 + MCP09 2 controls CONTROL 11 Per-call audit logging MCP08 — immutable, structured JSON CONTROL 12 Shadow server detection MCP09 — registry vetting, drift monitoring OWASP MCP TOP 10 MAPPED OWASP MCP01-10 Spec 2026-07-28 Microsoft AGT NIST AI Agent CSA 1,467 exposed servers, zero auth 82% path traversal exposure 78.3% attack rate at 5 servers 8.5% use OAuth today 12 controls across 5 layers — ideabosque.com/library

層級 1 — 傳輸與網路

控制 1：SSE 到 Streamable HTTP 遷移。 MCP 2026-07-28 規範 於 2026 年 7 月 28 日正式發布，對 HTTP+SSE 傳輸實施 12 個月棄用策略。四個 Tier 1 SDK（TypeScript、Python、Go、C#）在發布日均支援新的無狀態核心，並附帶破壞性變更遷移說明。Trend Micro 掃描中的 1,227 台棄用 SSE 伺服器是受影響最大的群體——它們執行的是規範正在淘汰的傳輸。**驗證：**檢查伺服器的傳輸設定。如果它提供 SSE，則已進入棄用倒數。在 12 個月窗口關閉前遷移至 Streamable HTTP。

控制 2：網路隔離與來源驗證。 CVE-2026-59950——已在 National Vulnerability Database 中確認——是官方 MCP Python SDK 中缺少 Host/Origin 驗證的缺陷。受害者造訪的網頁可透過 DNS rebinding 和 CSRF 驅動其本地 MCP 伺服器。瀏覽器成為攻擊者進入操作員認為私有的環回伺服器的代理。**驗證：**確認伺服器在每個請求上驗證 Host 和 Origin 標頭。如果伺服器面向網際網路，確認它位於阻止來自不可信來源直接存取的網路邊界之後。一個本不應從公共網際網路可達的伺服器絕不能從公共網際網路存取。

層級 2 — 認證與身分

控制 3：OAuth 2.1 + OIDC 強制執行。 2026-07-28 規範將 OAuth 2.1 加 OpenID Connect 設為強制——從先前的「自帶權杖」方式轉變。WorkOS 認證遷移指南 詳述了要求：RFC 8707（Resource Indicators）防止權杖跨伺服器重放，Client ID Metadata Documents 取代 Dynamic Client Registration，issuer 驗證（RFC 9207）。Practical DevSecOps 的發現——僅 8.5% 的受調查伺服器使用 OAuth——是這項控制要提升的基線。**驗證：**檢查伺服器的認證設定。如果它接受未認證請求或使用無 OAuth 的靜態 API key，則不合格。確認伺服器實作 RFC 8707 resource indicators。

控制 4：Agent 身分分離。 NIST AI Agent Standards Initiative（2026 年 2 月）提議將 agent 視為具有自身生命週期的獨立非人類身分：佈建、證明、撤銷。大多數部署認證人類使用者並將該身分傳遞給 agent。當 agent 採取行動時，稽核日誌記錄的是人類做的。**驗證：**確認每個 agent 擁有獨立於人類操作員的憑證（OAuth token、SPIFFE SVID）。撤銷 agent 身分應停止所有 agent 呼叫，而不影響人類的存取。

層級 3 — 工具註冊與供應鏈

控制 5：工具投毒掃描。 OWASP MCP03 將工具投毒列為 top-10 風險：rug pulls（受信任工具安裝後更新為惡意版本）、schema poisoning（介面定義本身被破壞以誤導模型）、tool shadowing（假工具攔截發給真工具的呼叫）。Microsoft Agent Governance Toolkit 的 McpSecurityScanner 偵測工具投毒、typosquatting 和隱藏指令——一個名為 read_flie（typosquatting read_file）的示範工具在描述中注入內容後評分 85/100 風險。**驗證：**檢查工具註冊流程。如果工具在無安全掃描的情況下註冊，則不合格。掃描必須覆蓋描述中的 prompt injection 模式、針對已知工具名的 typosquatting，以及隱藏的系統指令。

控制 6：簽名溯源與依賴監控。 OWASP MCP04 覆蓋供應鏈攻擊和依賴篡改。Postmark MCP 後門——野外捕獲的第一個惡意 MCP 伺服器——是一個看似合法的 npm 套件，靜默攔截並外洩郵件。它通過了註冊審查。UpGuard 的研究發現每 15 個 MCP 伺服器中就有一個是旨在冒充合法服務的 lookalike。**驗證：**確認部署中的每個 MCP 伺服器都有簽名溯源記錄和 AIBOM（AI Bill of Materials）清單。確認依賴監控處於活動狀態並在依賴樹中出現新 CVE 時告警。

控制 7：STDIO 強化。 OX Security 的揭露 識別出 STDIO 設定中影響 150M+ 下載量的架構級 RCE。根因：TypeScript SDK 中的 shell: true 透過設定字串啟用了命令注入。Cloud Security Alliance 將此歸類為系統性設計缺陷問題。**驗證：**如果伺服器使用 STDIO 傳輸，確認設定了 shell: false 或等效強化。確認命令 allowlist 檢查參數，而非僅檢查二進位名——Upsonic 和 Flowise 的繞過（CVE-2026-30625、CVE-2026-40933）表明 npx -c <惡意命令> 能通過僅檢查二進位的 allowlist。

層級 4 — 執行時與執行

控制 8：速率限制。 每個工具在註冊呼叫中宣告自己的速率限制。骨幹網按 agent、按工具、按視窗執行限制。當達到限制時，agent 收到帶 Retry-After 標頭的 429 回應。被入侵的 agent 無法耗盡上游 API 配額，因為速率限制在模組邊界執行。**驗證：**確認每個註冊工具都有速率限制。確認限制在模組邊界執行，而非在上游 API 執行。沒有速率限制的工具是被入侵 agent 可無限制呼叫的工具。

控制 9：上下文邊界。 OWASP MCP10 將上下文注入和過度共享列為 top-10 風險。具有廣泛上下文存取權的 agent 會跨租戶、工作階段或使用者洩漏資訊——對於同一 agent 服務於具有不同資料存取權限的多個客戶的 B2B 部署，這一擔憂尤為突出。**驗證：**確認每個工具僅接收其特定操作所需的上下文。確認上下文視窗按工具劃分，而非在所有工具間全域共享。一個在只需單一欄位時接收完整工作階段上下文的工具是資料洩漏面。

控制 10：按模組 kill-switch。 每個 MCP 模組必須能獨立停用，而無需觸碰編排骨幹。kill switch 是設定變更，不是程式碼部署。當漏洞揭露時——如 7 月 CVE 波在兩週內揭露了 3 個 SDK CVE 和 7+ 伺服器 CVE——操作員的首要問題是：我能否在不中斷 agent 的情況下停用此模組？在受治理的部署中，答案是肯定的。**驗證：**確認每個模組可透過 feature flag 或設定變更停用。確認停用路徑已經過測試——不只是設定過。一個從未被觸發過的 kill switch 在需要時將會失效。

層級 5 — 稽核與遙測

控制 11：每次呼叫稽核日誌。 OWASP MCP08 將缺乏稽核和遙測列為 top-10 風險。沒有工具呼叫和上下文變更的日誌，權杖竊取和注入仍然不可見。每次工具呼叫必須記錄時間戳、agent ID、工具名、輸入雜湊（非原始輸入——PII 邊界）、輸出狀態、持續時間和上游系統。日誌是傳送至可觀測性管道的結構化 JSON。**驗證：**確認每次工具呼叫產生結構化日誌條目。確認日誌包含輸入雜湊而非原始輸入。確認日誌不可變——入侵伺服器的攻擊者無法重寫稽核軌跡。

控制 12：影子伺服器偵測。 OWASP MCP09 覆蓋影子 MCP 伺服器——對治理不可見的未批准或未監督部署。UpGuard 發現每 15 個 MCP 伺服器中就有一個是 lookalike。安裝了錯誤的 mcp-server-postgress（注意拼寫錯誤）的工程師獲得了一個靜默外洩 SSH 金鑰和 .env 檔案的套件。**驗證：**確認有部署中每個 MCP 伺服器的清單。確認清單與已知良好套件登錄檔核對。確認 drift 監控在出現不在清單中的新伺服器時告警。

框架如何對映到清單

控制 OWASP MCP Spec 2026-07-28 Microsoft AGT NIST CSA
1. SSE 遷移 — 12 個月棄用 — — —
2. 網路隔離 MCP07 來源驗證 — — —
3. OAuth 2.1 + OIDC MCP07 強制認證 — OAuth 2.0 —
4. Agent 身分 MCP07 — AgentMesh Identity SPIFFE/SPIRE —
5. 工具投毒掃描 MCP03 — MCP Security Gateway — —
6. 簽名溯源 MCP04 — — — —
7. STDIO 強化 MCP05 — — — 系統性設計缺陷
8. 速率限制 — — Policy Engine — —
9. 上下文邊界 MCP10 — Response sanitizer — —
10. 按模組 kill-switch — — Hypervisor kill switch — —
11. 每次呼叫稽核日誌 MCP08 — Audit + metrics — —
12. 影子伺服器偵測 MCP09 — — — —

沒有任何單一框架覆蓋全部 12 項控制。清單是 OWASP、規範、Microsoft、NIST 和 CSA 的交集——每個框架貢獻其他框架缺失的控制。Microsoft Agent Governance Toolkit 覆蓋 10/10 OWASP MCP Top 10 類別（7/10 完整，3/10 部分並有路線圖），是首個具備顯式 OWASP 對映的超大規模廠商開源執行時——Agent OS Policy Engine 中 68 項測試，MCP Security Gateway 中 127 項測試，Agent Hypervisor Execution Control 中 80 項測試包括 kill switch。

評分清單

生產就緒的 MCP 伺服器通過全部 12 項控制。部分就緒的伺服器通過 8–11 項。通過少於 8 項的伺服器不應在無文件化補救計畫和每項失敗控制的目標日期下暴露於生產流量。

得分 狀態 行動
12/12 生產就緒 帶監控部署
8–11/12 部分就緒 帶文件化例外和補救時間線部署
<8/12 未就緒 不部署。先補救失敗的控制

最常見的失敗模式是通過控制 1–4（傳輸、認證、身分）而未通過控制 5–12（供應鏈、執行時、稽核）。前四項是架構性的，在設計審查中受到關注。後八項是營運性的，在事件或稽核暴露前常被忽視。2026 年 7 月的 CVE 波——兩週內 3 個 SDK CVE 和 7+ 伺服器 CVE——就是營運控制缺失時的後果。

相關閱讀

一個代表性建構：一家中型分銷商部署一個 MCP 模組，讀取 NetSuite 目錄、生成報價、保持庫存可用性，並將接受的訂單寫回 ERP。控制 1–4（SSE 遷移、網路隔離、OAuth、agent 身分）是架構。控制 5–8（工具投毒掃描、簽名溯源、STDIO 強化、速率限制）是供應鏈和執行時層。控制 9–12（上下文邊界、kill switch、稽核日誌、影子偵測）是決定模組執行一週還是一年的營運層。一週的 Discovery 階段產出系統清單和工作流圖，使每項控制可在模組接觸生產流量前驗證。

一週 Discovery。你獲得系統清單、工作流圖和固定範圍——無論你是否與我們合作建構。

想為您的系統建構這個嗎？

這裡的每份文件都來自真實的生產工作。如果您有目標系統和工作流程想法，我們可以在一週內確定範圍。

申請客製開發

為期一週的發掘階段。您會拿到系統清單、工作流程地圖和固定範圍——無論您最終是否與我們合作開發。