獨立安全研究員 Syed Anas Mohiuddin 十月發表跟進報告，指出 MCP（Model Context Protocol）伺服器普遍存在同一類伺服器端請求偽造（SSRF）錯誤：谷歌、摩根大通、Weaviate、法國跨部門數碼總署（DINUM）及印尼丹格朗市政府五個互不相干的團隊，各自確認並修補了他通報的同類漏洞；谷歌為此發出的 CVE 獲評 8.0 分（高危）。

他把這類攻擊稱為「協定跳板」（Protocol Pivoting）：惡意指令經 MCP 工具輸出混入代理流程，再透過 A2A 等代理間委派協定傳到下游代理，下游代理因信任上游而照單執行。Ars Technica 引述 Rapid7 專家指，鏈上每個環節都「按設計運作」，正正是難以察覺的原因。對正把 AI 代理接入內部系統的企業而言，這是零信任原則在代理時代的又一次警號。

獨立研究員／Ars：MCP「協定跳板」攻擊——同一 SSRF 漏洞先後獲谷歌、摩根大通、Weaviate、法國 DINUM 及印尼丹格朗市府確認修補；谷歌 CVE 評 8.0；美國聯邦五個 MCP 伺服器仍待處理

Ars Technica 資深安全編輯 Dan Goodin 十月五日報道，過去五個月內，谷歌等多個機構先後承認其 AI 代理相關元件存在可被「一個代理傳染另一個代理」的漏洞。本文以研究員本人發表的跟進報告為主要依據，並逐項核對美國國家漏洞資料庫（NVD）的 CVE 紀錄及 Rapid7 漏洞資料庫，來源真實性已驗證。下文拆解漏洞成因、受影響範圍、與企業部署 AI 代理的實際啟示。

一、核心事件：同一個錯誤，五個團隊各自確認

Mohiuddin 在五月首次發表報告時，只有一個公開例子：微軟 playwright-mcp 的 browser_navigate 工具接受代理提供的任何網址而沒有 SSRF 防護，代理可被引導至雲端執行個體中繼資料服務（169.254.169.254）索取憑證。他當時以公開 GitHub issue 提出，並強調該案沒有 CVE、亦未獲廠方確認。

四個月後的跟進報告列出經各機構自身安全團隊確認的個案：

谷歌（CVE-2026-14540）：MCP Toolbox for Databases（googleapis/mcp-toolbox）的 HTTP 用戶端初始化時沒有設定 CheckRedirect 重新導向政策，亦沒有驗證目標 IP。NVD 紀錄顯示受影響版本為 0.3.0 至 1.4.0，谷歌以 CVSS 4.0 評為 8.0 分（高危），NVD 自行以 CVSS 3.1 評為 6.1 分（中危）；CVE 於七月三日預留、七月三十一日公開。
摩根大通：其開源 jpmorgan-payments/ai 儲存庫內一個文件搜尋 MCP 伺服器，read_documentation 工具有網域允許清單，但姊妹工具 related() 卻會直接抓取呼叫方提供的任何網址。研究員指該元件分支自 AWS 專案，原版從不抓取呼叫方網址，改寫時加入了抓取功能卻漏了允許清單。摩根大通負責任披露團隊已確認並部署修補，屬中度風險。
Weaviate：合併 PR #12961，把 Google 模組的 apiEndpoint、region、location 參數限制為 Google API 主機。
法國 DINUM：國家開放數據平台官方 MCP 伺服器 datagouv-mcp 中，由數據提供者填寫的網址欄位會被伺服器抓取，可被 DNS 重新綁定利用並觸及雲端中繼資料；PR #126「harden SSRF on external APIs」於九月四日合併。
印尼丹格朗市政府：其 Wazuh MCP 伺服器的 blueteam_check_webshell 工具聲稱有 SSRF 防護，但只攔截字面 IP 位址、不解析主機名稱；維護者於九月三日發出 GitHub 安全公告 GHSA-pw2j-pj4h-f5vg（高危）。

此外，Rapid7 為其 Bulk Export MCP 伺服器發出 CVE-2026-97228：0.2.5 至 0.6.1 版會把未經驗證的 export_id 直接拼接入 GraphQL 查詢，CVSS 3.1 評 2.7 分（低危），0.6.2 版改用參數化變數修補。研究員坦言這不屬 SSRF、亦不嚴重，但同樣是「跨越 MCP 邊界的值未經驗證便進入下游請求」。

技術細節：仍在處理中的政府個案

報告另列出美國總務署（GSA）技術轉型服務旗下五個 MCP 伺服器，涵蓋退伍軍人事務部福利申索、CMS Blue Button、regulations.gov、USASpending 及 CDC PLACES，研究員於九月二日以私密安全公告通報，至今仍在分流中。以退伍軍人事務部個案為例，上游 API 出錯時伺服器會把完整回應內容以 ERROR 級別寫入日誌而不作遮蔽，內容可能包括姓名、社會安全號碼、出生日期及地址；一般驗證失敗已足以觸發。日本數碼廳的 jgrants-mcp-server 亦被指缺乏身份驗證，相關修正 PR 尚未合併。研究員明言，這些個案未修補，不應視作已確認結果。

二、技術原理深度解析

報告把問題歸納為兩種失效模式：

第一，SSRF。 MCP 伺服器向代理暴露工具，代理以參數呼叫，其中不少參數本身就是網址、路徑或端點。若伺服器未檢查該值實際解析到哪裏便發出請求，等於讓代理決定伺服器的網絡身份去連接甚麼；而代理會閱讀不受信任的內容並據此行動，任何能把文字放到代理面前的人，都可能借此操控伺服器。

第二，不安全處理上游數據。 伺服器把上游 API 回應原封不動寫入集中式日誌，毋須任何攻擊，日常錯誤已會令敏感資料外洩。

兩者源自同一假設：開發者以為跨越 MCP 邊界的數據「來自系統內部」所以可信。研究員指，在代理管線中這個假設並不成立。

「協定跳板」則是把上述錯誤串連起來：實際部署往往同時使用 MCP（工具）、A2A（代理間委派）及 ANP 等探索協定。攻擊者在 MCP 工具回傳內容中植入形似 A2A 任務指令的文字，編排代理把它當作正常委派交給子代理；子代理信任編排者而執行，若子代理所連的 MCP 伺服器有 SSRF，請求便以伺服器的網絡身份發出。

業界對命名有不同看法。X41 D-Sec 研究員 Markus Vervier 對 Ars 表示，這本質上是間接提示注入（indirect prompt injection）的子類，惡意提示來自另一協定並非攻擊成立的必要條件，但他亦承認這類攻擊「出人意表且整體難以緩解」。Rapid7 漏洞情報總監 Douglas McKee 則指，每個協定都假設自己獨立存在，「各自守好前門，卻沒有人看守中間的走廊」；他建議把 LLM 傳給工具的一切，視為來自互聯網陌生人的輸入。

谷歌的修補被研究員視為範例：PR #3448 在連線時才檢查解析後的位址，令 DNS 重新綁定無法在檢查與使用之間調包目標；套用 IP 範圍允許及封鎖清單；並在啟動時便拒絕不安全的基礎網址，而非等到第一次請求。

三、日常應用場景

1. 開發者與技術團隊

凡自建或引入第三方 MCP 伺服器，應逐一盤點哪些工具參數會被組成對外請求，並在解析後的 IP 層面套用允許清單、封鎖私有網段、回送位址及雲端中繼資料位址；分支或改寫開源元件時，須與上游版本逐行對照，摩根大通個案正是改寫過程中遺漏防護。

2. 企業與隱私敏感行業

金融、醫療及公營機構在 AI 代理之間建立委派關係時，應回歸零信任：子代理執行敏感操作前須獨立授權，不能因任務來自內部代理便放行。日誌管線亦應對上游回應做遮蔽，避免個人資料在「正常出錯」時寫入集中式日誌。

3. 一般用戶

個人使用桌面 AI 助手接駁各類 MCP 工具時，宜只安裝來源可信、維護活躍的伺服器，並留意更新；例如使用谷歌 mcp-toolbox 的用戶，應確認已升級至 1.4.0 以後的修補版本。

4. 香港與亞洲市場視角

今次確認個案橫跨美國、法國及印尼市政府，日本數碼廳的伺服器亦被點名，顯示亞洲公營部門同樣已把 MCP 投入實際部署。香港企業與機構近年積極試行生成式 AI 及代理工作流程，若代理需要存取客戶資料，除技術防護外，亦須考慮《個人資料（私隱）條例》下的資料保安責任：日誌外洩個人資料，即使並非黑客入侵所致，同樣可能構成合規風險。

四、專業評價與潛在考量

優勢

個案均經各機構自身安全團隊確認，並有 CVE、GitHub 安全公告或已合併 PR 可供公開核對，並非單一研究員的推論。
修補方法屬成熟做法（允許清單、解析後驗證、參數化查詢），企業可直接套用至自家 MCP 伺服器。

需要留意的地方

「協定跳板」是否應獨立成類仍有爭議；Vervier 認為它只是間接提示注入的一種。
各漏洞嚴重程度差異大：谷歌個案由 CNA 評 8.0 分、NVD 評 6.1 分，Rapid7 個案僅 2.7 分，摩根大通個案屬中度且偽造請求不附帶憑證；不宜一概而論為「重大漏洞」。
美國聯邦及日本數碼廳個案仍未修補，細節有待官方回應。

結語

MCP 面世不足兩年便已廣泛投入生產，今次五個毫無關連的團隊犯下同一錯誤，說明問題在於開發習慣與協定生態，而非個別疏忽。隨着 MCP、A2A 等協定串連愈來愈多代理，「內部即可信」的假設必須拋棄。企業若要在香港把 AI 代理接入核心系統，可參考 YSK Limited 的雲端遷移與網絡安全服務（官網刊 99.99% SLA，https://ysk.hk/services/cloud-security）檢視零信任架構；如需把模型與數據留在自家環境，亦可了解企業私有 LLM 全託管，年費 HK$88,000 起，數據不出境（https://ysk.hk/services/ai-automation）。

參考來源

Syed Anas Mohiuddin，〈Protocol Pivoting, four months later〉（研究員跟進報告，2026 年 10 月）：https://anas-security-portfolio.vercel.app/protocol-pivoting-update.html
NVD，CVE-2026-14540（Google mcp-toolbox SSRF）：https://nvd.nist.gov/vuln/detail/CVE-2026-14540
Rapid7 Vulnerability Database，CVE-2026-97228：https://www.rapid7.com/db/vulnerabilities/cve-2026-97228/
Ars Technica（Dan Goodin），〈MCP for agent-to-agent comms may be the riskiest protocol you've never heard of〉，2026 年 10 月 5 日：https://arstechnica.com/security/2026/10/vulnerability-in-agents-from-google-and-others-exposes-structural-flaw-in-mcp/
Model Context Protocol 官方文件：https://modelcontextprotocol.io/