你昨天讓 AI 幫你查了 AWS 帳單、讀了 Slack 訊息、或是自動整理了一份報告。

在這些操作的背後，有一個叫做 MCP（Model Context Protocol） 的協定正在負責 AI 與外部工具之間的通訊。而 2026 年 4 月，三個針對 MCP 生態的 CVE 被相繼公開，每一個都直指同一個問題：我們太信任工具了。

這篇文章拆解這三個漏洞的技術細節，並從防禦設計的角度提出具體的緩解思路。

背景：MCP 生態的攻擊面正在急速擴大

在深入個別 CVE 之前，需要先看清全局。

根據安全研究者在 2026 年初的調查，2,614 個 MCP 實作中，約 82% 的檔案操作存在路徑遍歷風險，超過三分之二有某種形式的程式碼注入可能（來源）。2026 年 1-2 月短短 60 天內就出現了超過 30 個 MCP 相關的 CVE，其中 43% 屬於指令注入（exec/shell injection）類型。

這不是偶然。MCP 伺服器的本質是「指令行工具的薄包裝」——開發者很容易直接把使用者輸入丟進 exec() 或 subprocess.run()，而 AI Agent 對工具描述的隱性信任又進一步放大了攻擊面。

以下三個 CVE，分別展示了三種不同層次的 MCP 安全問題。

CVE-2026-5058：aws-mcp-server 指令注入 RCE

漏洞本質：aws-mcp-server 在處理「允許的指令清單」時，未對使用者提供的字串進行驗證，就直接將其傳入系統呼叫執行。攻擊者不需要任何身份驗證，只要能夠透過網路存取到 MCP 伺服器實例，就能注入任意指令，在伺服器的執行環境中達成 RCE。

為什麼嚴重：CVSS 向量為 AV:N/AC:L/PR:N/UI:N——網路可達、低攻擊複雜度、無需權限、無需使用者互動。這是一個標準的「未授權遠端程式碼執行」組合。考慮到 aws-mcp-server 通常運行在有 AWS 憑證的環境中，一旦被攻破，攻擊者可能直接存取雲端資源。

值得注意的是，同一天還公開了 CVE-2026-5059（ZDI-26-245），也是 aws-mcp-server 的 AWS CLI 指令注入，同樣 CVSS 9.8，同樣 0-day。這表示該產品的輸入驗證存在系統性的設計缺陷，而不只是單點疏忽。

防禦設計要點：

• 在 MCP 伺服器與實際系統指令之間加入白名單驗證層，只允許預定義的指令模式通過
• 使用參數化執行（如 Python 的 subprocess.run 搭配 list 參數）取代字串拼接
• 在 AI Agent 呼叫 MCP 工具前設置 policy 檢查點，攔截異常的指令模式

CVE-2026-6130：Chatbox MCP 傳輸層指令注入

漏洞本質：Chatbox 的 MCP Stdio 傳輸實作（src/main/mcp/ipc-stdio-transport.ts）中，StdioClientTransport 函式接受的 command、args、env 參數完全未經驗證就被用於產生子程序（來源）。更嚴重的是，攻擊鏈可以串聯：

1. 攻擊者透過深層連結（Deep Link）或匯入惡意 JSON 設定檔，將惡意 MCP 伺服器配置寫入應用程式的儲存空間
2. 應用程式重啟時，mcp_bootstrap.ts 自動啟動所有已啟用的 MCP 伺服器
3. 惡意指令被執行——從使用者匯入檔案到 shell 執行，中間零次額外互動

為什麼嚴重：這不只是一個傳輸層的輸入驗證問題。它揭示了桌面端 AI 應用的一個結構性風險：MCP 伺服器配置本身就是一個攻擊向量。當應用程式信任匯入的設定資料、自動啟動 MCP 伺服器、且 IPC 通道暴露了原始的 invoke 方法時，攻擊者只需要讓使用者開啟一個檔案。

防禦設計要點：

• MCP 伺服器配置的匯入必須經過 schema 驗證和白名單過濾，特別是 command 欄位
• 新增或變更的 MCP 伺服器不應自動啟動，需要使用者明確確認
• IPC 通道應該限制可呼叫的方法，而不是直接暴露 ipcRenderer.invoke

CVE-2026-33946：MCP Ruby SDK Session Hijacking

漏洞本質：MCP Ruby SDK 的 streamable_http_transport.rb 在建立 SSE（Server-Sent Events）連線時，未正確綁定 session 與客戶端身份。攻擊者只要取得一個有效的 session ID，就可以完全劫持受害者的 SSE 串流，攔截所有即時傳輸的資料（來源）。

為什麼嚴重：SSE 是 MCP 協定中用於即時資料推送的核心傳輸機制。被劫持的串流可能包含 AI Agent 的工具呼叫結果、使用者查詢內容、甚至是存取令牌等敏感資料。攻擊向量為 AV:N/AC:L/PR:N/UI:N——無需認證、無需使用者互動即可遠端利用。

值得注意的是，官方的 Python SDK、Go SDK、C# SDK 在對應的實作中都有正確的 session 綁定邏輯，這表示這是 Ruby SDK 特有的實作缺陷。修補也很明確：升級到 0.9.2 即可。

防禦設計要點：

• SSE 連線建立時必須驗證 session 擁有者的身份，而不是只檢查 session ID 是否存在
• session ID 應在每次 SSE 連線時重新產生（防止 fixation）
• 如果你的 MCP 伺服器使用 Streamable HTTP 傳輸，無論用哪個 SDK，都應該檢查 session 管理邏輯是否有類似的綁定不足問題

三個 CVE 的共同教訓

把三個漏洞排在一起看，會發現一條清晰的脈絡：

MCP 生態的安全問題不在於協定本身的設計，而在於實作者對「信任邊界」的認知不足。當 AI Agent 可以自主決定呼叫哪些工具、傳入哪些參數時，每一個 MCP 伺服器都是一個潛在的提權入口。

如果你正在運行 MCP 伺服器，以下是最基本的檢查清單：

• 所有接受外部輸入的指令執行路徑，是否都有白名單驗證？
• MCP 伺服器設定的匯入/變更，是否需要使用者明確確認？
• SSE/WebSocket 等持續連線的 session 管理，是否正確綁定了客戶端身份？
• AI Agent 呼叫工具前，是否有獨立於工具本身的 policy 檢查層？

參考資料

• NVD - CVE-2026-5058
• ZDI-26-246 Advisory
• NVD - CVE-2026-6130
• chatboxai/chatbox Issue #3627
• GitLab Advisory - CVE-2026-33946
• MCP Ruby SDK v0.9.2 Release
• MCP Security 2026: 30 CVEs in 60 Days