MCP 安全：為何 20 萬個易受攻擊的實例讓受治理模組成為採購標準

這次披露

2026 年 4 月和 5 月，OX Security 披露了模型上下文協定（MCP）STDIO 配置中的一個系統性架構缺陷，該缺陷可導致命令注入和遠端程式碼執行。該公告涵蓋 MCP 供應鏈中的 10 個 CVE——估計有 20 萬個易受攻擊的實例，觸及 1.5 億次下載。這個漏洞並不在單一套件中，而是在大多數社群 MCP 伺服器出廠時採用的預設配置模式裡。

Cloud Security Alliance 將其研究筆記命名為「MCP 安全危機：AI 代理基礎設施中的系統性設計缺陷」。OWASP 啟動了 MCP Top 10 專案，以編纂 MCP 支援系統生命週期中最關鍵的安全問題。Aembit 發布了一份涵蓋傳輸風險和供應鏈威脅的指南。TrueFoundry 發布了一份 MCP 安全風險與最佳實務的企業指南。

它們共通的模式是：這個漏洞面之所以存在，是因為社群 MCP 伺服器在建構和部署時，缺少生產系統所要求的治理層。

這個漏洞究竟是什麼

MCP 伺服器透過某種傳輸方式與 AI 代理用戶端通訊。STDIO 傳輸——本地開發和許多生產部署的預設方式——透過標準輸入和輸出來傳遞訊息。OX Security 披露指出，常見的 STDIO 配置模式允許命令注入：精心構造的輸入可以在執行 MCP 伺服器的主機上執行任意命令。

這並非理論上的攻擊路徑。MCP 伺服器與代理用戶端執行在同一台機器上，具有相同的行程權限。一個根據透過 STDIO 收到的輸入來接受並執行 shell 命令的伺服器，本質上就構成了一個遠端程式碼執行面。20 萬個實例的估計反映了社群 MCP 採用的規模——這些伺服器被發布到登錄庫、從儲存庫克隆，並以從未針對生產環境加固的預設配置部署。

Backslash Security 另外指出了 MCP 2026-07-28 候選發布版本本身引入的三個新攻擊面——正是這份將在 20 天後定案的規範。新能力（伺服器渲染的 UI、長時間執行的任務、基於標頭的路由）帶來了新的入口點，而安全社群仍在梳理這些入口。

2026 年的漏洞時間線

OX Security 的披露並非孤立事件。它處於一條在 2026 年上半年不斷擴大的漏洞時間線之中，而這些具名漏洞正是把「治理是良好實踐」變成「治理是採購標準」的原因。

2026 年出現了四個新 CVE：CVE-2026-33032（「MCPwn」，CVSS 9.8，超過 2,600 個暴露實例）、CVE-2026-0755（Gemini MCP 工具，CVSS 9.8）、CVE-2026-35394（Mobile MCP RCE，2026 年 4 月，Android intent injection，CWE-939），以及 2026 年 2 月一個偽造的 Oura MCP 木馬分發 StealC 惡意軟體。Practical DevSecOps 發現，30–82% 的公共 MCP 伺服器帶有可利用缺陷，只有 8.5% 使用 OAuth 進行身分認證。

更大的圖景更為嚴峻：47–53% 的組織在過去一年中報告了與代理相關的安全事件，只有 14.4% 的 AI 代理在獲得完整安全審批後進入生產環境。採用與治理之間的差距，正是 MCP 安全危機所在。

用戶端 OAuth RCE——一個新的攻擊類別

上述 CVE 都是伺服器端漏洞——MCP 伺服器是目標。2025 年 9 月，Obsidian Security 披露了一個完全不同的攻擊類別，其目標是用戶端主機。MCP Authorization 規範的 OAuth 探索流程開啟了一道後門：為 OAuth 而啟動瀏覽器、卻未對 URL 做淨化的桌面和 CLI MCP 用戶端，容易受到 OS 命令注入和遠端程式碼執行的攻擊。一個惡意的遠端 MCP 伺服器可以入侵用戶端機器。

已分配了四個 CVE，包括影響 Cherry Studio 的 CVE-2025-54074。受影響的用戶端遍佈整個生態系：Cherry Studio、Gemini-CLI、MCP Inspector、VS Code、Windsurf、Smithery.ai、Lutra.ai 和 Glue.ai。這個攻擊不需要一個有漏洞的伺服器——它需要的是一個有漏洞的用戶端連到攻擊者控制的任何伺服器。

這個類別與伺服器端供應鏈攻擊不同，因為緩解位於不同層。伺服器端加固（稽核日誌、速率限制、型別化錯誤、kill-switch）無法保護用戶端主機。用戶端必須在啟動瀏覽器之前對 OAuth 重新導向 URL 做淨化，並驗證探索文件。啟動瀏覽器的框架必須限制它會開啟哪些 URL。

BlueRock Security 發現，在 7,000 多個被掃描的 MCP 伺服器中，有 36.7% 容易受到伺服器端請求偽造（SSRF）攻擊——這種攻擊讓一個被入侵的 MCP 伺服器可以從它執行的主機上發出任意對外請求。結合 Obsidian 的用戶端發現，攻擊面現在橫跨連線的兩端：伺服器可以攻擊用戶端（OAuth RCE），伺服器也可以攻擊它執行所在的網路（SSRF）。

另外兩個 CVE 將時間線延伸到新的攻擊類別：

• CVE-2026-39313 — mcp-framework HTTP Server 阻斷服務。透過對 HTTP 傳輸層發出精心構造的請求造成記憶體耗盡。這是針對 MCP HTTP 傳輸的首例已記錄 DoS 攻擊，而非 RCE——一個新的漏洞類別。
• CVE-2026-33224 — Bisheng 在 MCP 工具配置內的已認證遠端命令執行。這將 STDIO 供應鏈公告延伸到一個新的受影響產品，證實配置層攻擊面並不局限於原始的 OX Security 披露。
• CVE-2026-27826 — MCP Atlassian SSRF（CVSS 8.2，sooperset:mcp-atlassian 版本 < 0.17.0）。此漏洞的獨特之處在於它是無需認證的，且存在於 HTTP 中介軟體和依賴注入層，而非任何 MCP 工具處理器中。僅關注工具處理器的安全審查會完全忽略 HTTP 傳輸層。在雲端部署中，SSRF 可透過實例元資料端點（169.254.169.254）竊取 IAM 角色憑證。中介軟體而非工具處理器的位置是工具級程式碼分析無法偵測的獨特攻擊面。

Reddit 的 r/AI_Agents 社群回報，在 60 天內（2026 年 1 月至 3 月）針對 MCP 伺服器提報了 30 個 CVE，超過 12,000 個暴露實例。Practical DevSecOps 證實，這 30 個 CVE 中有 13 個（約 43%）是命令執行漏洞。速度正在加快，而非趨於穩定。

治理層——稽核日誌、速率限制、型別化錯誤、kill-switch 架構、PII 邊界——處理的是伺服器端攻擊面。用戶端 OAuth RCE 類別需要用戶端層級的 URL 淨化，這是一個獨立的緩解措施，MCP 規範和用戶端框架仍在更新以強制執行。兩個層都需要。

為什麼社群伺服器是暴露點

大多數社群 MCP 伺服器的建構目的是展示某項能力——把代理連接到某個工具、回傳一個結果。它們並非為了被營運而建構。生產系統所要求的治理控制在預設情況下都是缺失的：

• 沒有稽核日誌。 工具呼叫沒有記錄請求、回應、延遲和結果。當事件發生時，沒有軌跡可供重建。
• 沒有速率限制。 工具可以被無限制地呼叫。一個被入侵或行為異常的代理可以耗盡上游 API 配額，或大規模觸發非預期的副作用。
• 沒有型別化錯誤契約。 錯誤以字串或非結構化回應形式回傳。代理無法區分暫時性故障與永久性故障，營運人員也無法以程式化方式分類事件。
• 沒有 kill-switch。 沒有維運 runbook、沒有回退路徑，也沒有辦法在不觸及編排主幹的情況下停用某個模組。
• 沒有測試覆蓋。 錯誤路徑未經測試。一個在開發中從未被觸發的故障模式，正是會在生產中爆發的那一個。

這些並不是什麼稀奇的安全要求。它們就是任何生產 API 都會強制執行的相同控制。差距在於，MCP 伺服器被當作開發工具而非生產整合來部署。

受治理模組長什麼樣

我們發布的 MCP 模組程式碼標準 定義了針對上述每一項差距的治理層。這份標準不是一個安全框架——它是一份讓安全變得可強制執行的程式碼標準。控制是具體的：

稽核日誌。 每次工具呼叫都記錄時間戳記、代理 ID、工具名、輸入雜湊（不是原始輸入——PII 邊界）、輸出狀態、時長和上游系統。日誌是推送到可觀測性管線的結構化 JSON。當事件發生時，稽核軌跡能從請求參數和 handle 重建完整的工作流程狀態——無需與 session-store 日誌做關聯。

速率限制。 每個工具在註冊呼叫中宣告自己的速率限制。主幹按代理、按工具、按視窗執行這些限制。當達到限制時，代理收到一個帶 Retry-After 標頭的 429 回應——它不會崩潰或盲目重試。被入侵的代理無法耗盡上游配額，因為速率限制是在模組邊界執行的，而不是在上游 API。

型別化錯誤契約。 模組拋出型別化例外——MCPAuthError、MCPRateLimitError、MCPTimeoutError、MCPValidationError、MCPUpstreamError——而不是裸字串。主幹捕獲這些例外並將其轉換為代理可推理的結構化回應。營運人員可以程式化地分類事件，因為每個錯誤都帶有一個錯誤碼。

PII 邊界處理。 模組宣告哪些輸入欄位包含 PII。主幹在記錄前對這些欄位做雜湊（SHA-256），絕不把原始 PII 發到稽核管線。工具 handler 仍然接收原始值——PII 處理在日誌邊界強制執行，而不在業務邏輯內部。

測試覆蓋。 每個工具都有請求/回應測試和錯誤路徑覆蓋。整合測試針對沙箱環境執行。Mock 測試驗證工具註冊、參數映射、回應正規化、錯誤傳播和狀態轉換。一個在開發中從未被觸發的故障模式不會被交付出去。

38 個工具的驗證點

這些控制並非空談。它們就是 mcp_hospirfq_processor 的結構——這個模組在完整的 RFQ 生命週期中註冊了 38 個工具：請求建立、目錄搜尋、報價產生、定價層級、可用性鎖定、取消策略、套餐發現和訂單移交。

該模組的錯誤處理器為每一種故障模式定義了型別化錯誤碼——GRAPHQL_QUERY_FAILED、VALIDATION_FAILED、HOLD_NOT_FOUND、HOLD_ALREADY_EXPIRED、AVAILABILITY_INSUFFICIENT、PRICING_MODE_UNSUPPORTED。每個錯誤都帶有一個錯誤碼和結構化細節。handle_errors 裝飾器包裹每個工具方法，因此沒有任何工具會回傳非結構化的例外。狀態管理器強制執行有效的狀態轉換——一個鎖定可以被確認、釋放或過期，但不能從初始直接跳到完成。

這就是受治理模組在實務中的樣子：每個工具都有 schema，每個錯誤都有錯誤碼，每次呼叫都有日誌，每個狀態轉換都有驗證器。治理在程式碼裡，而不在一份也許有人會讀的文件裡。

kill-switch 架構

治理層從模組延伸到編排主幹。工程簡報規定了營運姿態：

• 維運 runbook。 部署、回滾、事件回應和常見操作都有文檔記錄。當模組行為異常時，營運人員遵循的是 runbook，而不是一條 Slack 討論串。
• 回退路徑。 後端不可用時優雅降級。一個無法連上上游的模組會回傳結構化錯誤，代理則路由到回退工具或升級給人工。
• 特性開關灰度。 模組按環境啟用。一個模組可以在不觸及編排主幹的情況下被停用——kill switch 是一次配置變更，而不是一次程式碼部署。
• 可觀測性。 結構化日誌、指標和 traces 推送到監控堆疊。代理的行為端到端可稽核——這正是企業應用於財務控制的同樣姿態。

kill-switch 架構正是 OX Security 披露所揭露的、在 20 萬個社群伺服器中缺失的那個控制。當一個漏洞被披露時，營運人員的第一個問題是：我能不能在不讓代理停擺的情況下停用這個模組？在受治理的部署中，答案是可以。在社群伺服器的部署中，答案通常是不行——伺服器被接進了代理的工具清單，移除它需要修改程式碼並重新部署。

為什麼這現在成了採購標準

PwC 2026 全球 CEO 調查（4,454 位 CEO）發現，56% 的組織報告 AI 沒有帶來可衡量的財務效益。WRITER 企業 AI 採用調查發現，35% 的企業一旦部署了某個 AI 代理，就無法把它關掉。兩者結合就是採購標準：一個無法被停用的系統是一種負債，一個不產生可衡量效益的系統是一種成本。治理——稽核日誌、速率限制、型別化錯誤、kill-switch 架構——正是讓 AI 代理既能安全部署又能安全退役的控制。

Gartner 預測，到 2026 年底，因 AI 風險護欄不足而導致的「death by AI」法律索賠將超過 2,000 起。歐盟 AI 法案將於 2026 年 8 月 2 日全面適用——距今 25 天。第 50 條透明度規則要求揭露 AI 生成內容。風險分類、文檔記錄和留存記錄對高風險系統將成為強制要求。受治理模組本就出廠即帶的稽核日誌和維運 runbook，正是歐盟 AI 法案將要求的合規證據。

MCP 2026-07-28 規範將在 20 天後定案。當它發布時，「Model Context Protocol」的搜尋量和引用量將激增——對安全面的審視也會隨之增加。那些達不到治理門檻的社群伺服器，就是會被標記出來的那些。

決策

當一個團隊評估基於 MCP 的代理部署時，問題不再是「它連得上嗎？」社群伺服器連得上。問題是：當出了差錯時，你能不能看見它、停下它，並證明發生了什麼？

受治理模組對這三點都回答「能」。社群伺服器在預設情況下對這三點都回答「不能」。那 20 萬個易受攻擊的實例就是證據。

---

一家使用 NetSuite、BigCommerce 和三個供應商目錄的經銷商會得到一個代理：它透過郵件或門戶接收 RFQ，對照目錄圖譜解析產品和替代品，按客戶層級定價，帶過期時間鎖定庫存，並把已接受的報價寫回 NetSuite——每一步都有日誌，每個工具都被限流，每個模組都可透過配置停用。這個建構屬於四步方法的第 2–3 階段，通常 5–8 週內上線。

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