2026 年 7 月 MCP 伺服器認證流行病：一個月 12 個專案、19 條漏洞、連官方 SDK 都中
目錄
2026 年 7 月 MCP 伺服器認證流行病：一個月 12 個專案、19 條漏洞、連官方 SDK 都中
如果你正在把 MCP 伺服器（Model Context Protocol server）接進 AI agent，這篇是給你在按下連線之前看的。
2026 年 7 月，短短三週內，我們清點到至少 12 個不同的 MCP 專案、共 19 條安全公告。從嚴重度 9.8 的記憶服務未認證讀寫，到 Grafana、n8n、LiteLLM 這種量級的專案，再到最關鍵的一項：官方 MCP Python SDK 參考實作本身，一個月內就佔了其中 3 條。
把這些攤開來看，會發現它們不是各自獨立的意外。同一類錯誤反覆出現：認證、來源驗證、租戶隔離，全都被當成「之後再說」的可選項。這篇不談理論，先把逐條查證過的清單給你，再拆解為什麼會這樣，最後給你一份接上 MCP 伺服器之前可以直接照做的檢查清單。
下面每一條都對 GitHub Advisory Database 第一手核對過，嚴重度分數只寫公告有給的，沒有的地方我們不編。
為什麼 MCP 伺服器特別容易踩這個坑
先講清楚背景，因為它決定了後面所有漏洞的形狀。
MCP 最早的心智模型是「跑在你自己電腦上的本機工具」。stdio transport、localhost、單一使用者。在那個模型裡，「反正只有我連得到」是成立的，所以很多實作根本沒寫認證，因為看起來不需要。
問題是，MCP 生態很快就長出了 HTTP、SSE、WebSocket 這些網路 transport，讓伺服器能被遠端連、被多個 client 共用、被部署到雲端。而「只有我連得到」這個假設，在網路 transport 下瞬間崩掉：
- 綁在
0.0.0.0上的伺服器，同網段甚至整個網際網路都連得到。 - 沒有驗證
Host或Originheader 的 HTTP/WebSocket 端點，會被瀏覽器裡的惡意網頁透過 DNS rebinding 打進來。 - 一台持有下游 API 金鑰的伺服器，如果不檢查「這個請求到底是誰發的」，就變成 混淆代理（confused deputy）：攻擊者不需要偷你的金鑰，只要叫伺服器替他用就好。
7 月的這批漏洞，幾乎每一條都能對回這幾個崩掉的假設。
逐條清單（2026-07-02 至 07-22，全部查證過）
第一類：完全沒有認證
端點直接對外服務，不問你是誰。這類最直接、也最嚴重。
| 專案 | 編號 | 嚴重度 | 問題 |
|---|---|---|---|
| mcp-memory-service | CVE-2026-50027 | Critical 9.8 | Document API 端點缺認證，未認證即可讀、寫、刪整個記憶庫 |
| mem0 | CVE-2026-59706 | Critical 9.3 | 未認證的 config API 直接明文吐出 LLM 金鑰 |
| netlicensing-mcp | CVE-2026-54446 | High 8.1 | 未認證即可使用伺服器端的 NetLicensing API 金鑰 |
| MCP Python SDK | CVE-2026-52869 | High 7.1 | HTTP transport 沒驗證 session 就服務請求 |
| PraisonAI（< 4.6.78） | CVE-2026-61427 | Medium | MCP HTTP-stream transport 預設沒有認證 |
mem0 那條特別值得停一下：一個記憶層產品，未認證端點直接把 OpenAI 金鑰交出去。你的 AI 記憶層，變成別人的金鑰提款機。
第二類：混淆代理與憑證盜用
伺服器自己有合法憑證，攻擊者不偷憑證，而是讓伺服器替他行動。
| 專案 | 編號 | 嚴重度 | 問題 |
|---|---|---|---|
| Grafana MCP Server | CVE-2026-15583 | High 8.6 | confused-deputy，未認證遠端攻擊者可外洩資料 |
| meta-ads-mcp | CVE-2026-54547 | High 7.4 | X-Pipeboard-Token header 認證繞過，重用 operator 的 Meta token |
| LiteLLM | CVE-2026-59822 | High | MCP 認證繞過：OAuth2 passthrough 的 fallback 路徑用了一個空的授權物件，任何 Bearer token 都能進到 MCP 工具鏈 |
LiteLLM 是目前最主流的開源 LLM gateway 之一，被大量企業當成統一的 LLM 控制平面。它一破，破的不只是自己，是整條接在它後面的下游 MCP 服務。
第三類：來源、session 與 rebinding 驗證缺失
端點沒檢查「這個連線從哪裡來、屬於哪個 session」。
| 專案 | 編號 | 嚴重度 | 問題 |
|---|---|---|---|
| MCP Python SDK | CVE-2026-52870 | High 7.6 | experimental task handler 允許任何 client 存取 |
| MCP Python SDK | CVE-2026-59950 | High | WebSocket transport 不驗證 Host / Origin |
| mcp-atlassian | GHSA-489g-7rxv-6c8q | Medium 6.5 | DNS-rebinding TOCTOU，繞過先前為 SSRF（CVE-2026-27826）打的補丁 |
mcp-atlassian 那條是個很好的教材：他們先前已經修過一次 SSRF，這次的漏洞是用 DNS rebinding 在檢查與使用之間的時間差（TOCTOU）繞過那個修補。補丁本身沒錯，是驗證的時機錯了。
第四類：SSRF 與出站繞過
| 專案 | 編號 | 嚴重度 | 問題 |
|---|---|---|---|
| meta-ads-mcp | CVE-2026-54549 | High 8.3 | upload_ad_image 的 SSRF |
| n8n | CVE-2026-59207 | High | 透過 AI Agents MCP 繞過「允許的 HTTP 網域」限制 |
| n8n | GHSA-vhf8-cg2h-cg3p | Medium | MCP Client Node 的 SSRF 防護繞過 |
第五類：路徑穿越與跨租戶授權
| 專案 | 編號 | 嚴重度 | 問題 |
|---|---|---|---|
| mcp-atlassian | GHSA-wm45-qh3g-v83f | High 7.7 | 附件上傳導致任意伺服器端檔案讀取 |
| mcp-atlassian | GHSA-g5r6-gv6m-f5jv | High 7.7 | confluence 缺路徑驗證的任意檔案讀取 |
| phantom-audio | GHSA-52vm-mxx8-f227 | High 7.7 | 未受限的 MCP tool 導致任意檔案寫入與解碼炸彈 DoS |
| n8n | CVE-2026-65594 | Medium | member 級用戶可執行他人的 MCP trigger workflow |
| langbot | CVE-2026-54449 | High 8.8 | 經認證後可透過 MCP 設定達成 RCE |
為什麼這是結構性的，不是運氣不好
一兩個專案出包，你可以說是個案。12 個專案在三週內犯同一類錯，那是模式。 而讓這件事從「一批粗心的下游專案」升級成「結構性缺口」的，是那三條屬於官方 MCP Python SDK 的公告。
參考實作是整個生態抄作業的對象。當連參考實作都在 HTTP transport 上不驗證 session、在 WebSocket 上不檢查 Host/Origin，那下游一堆專案犯一樣的錯，就一點都不意外了。這不是哪個工程師不小心，是整個 MCP 伺服器的建構方式裡，安全預設值站錯了邊：預設開放，要你自己記得關；而不是預設關閉，要你明確打開。
要精確一點：這 19 條裡有兩條（langbot 的 RCE、n8n 的跨租戶執行）根因其實是「已認證之後的授權隔離缺失」，不是認證本身被跳過。但它們反映的是同一種心態：邊界檢查被當成非必要。剩下的十幾條，反覆踩的就是四件事：
- 把「本機、單使用者」的假設帶到網路 transport 上，於是端點根本沒認證。
- 持有下游憑證卻不檢查請求來源，於是變成混淆代理。
- 不驗證 Host / Origin / session，於是 DNS rebinding 和跨 client 存取打得進來。
- 把認證做成可選設定而非強制預設，於是大多數部署跑在沒開的狀態。
接上任何 MCP 伺服器之前，檢查這幾件事
這份清單刻意做成「你今天就能拿去對照」的形式。不需要工具也能一條條問，但這正是靜態、上線前掃描最能幫上忙的地方，因為這些全都在設定與程式碼層面看得出來，不必等到被打。
認證面
- 伺服器的網路 transport（HTTP / SSE / WebSocket）有沒有強制認證？是預設開，還是要手動開？
- 有沒有任何端點在沒有 token 的情況下會回傳資料？特別注意 config、health、debug、document 這類「輔助」端點。
- 認證失敗的 fallback 路徑，是拒絕，還是默默放行？（LiteLLM 那條就是 fallback 放行。）
來源與 session 面
- WebSocket / HTTP 端點有沒有驗證
Host和Origin？（沒有就等著被 DNS rebinding。） - session 是綁定的，還是任何 client 都能拿別人的 session id 來用？
- 綁定的位址是
127.0.0.1還是0.0.0.0？後者代表整個網段連得到。
憑證與代理面
- 伺服器持有的下游 API 金鑰，會不會在不檢查「誰發的請求」的情況下被使用？（這就是混淆代理。）
- 多租戶場景下，member 級用戶能不能碰到別人的資源？
出站面
- tool 會不會依使用者輸入去抓 URL？有沒有 SSRF 防護？防護是不是也擋得住 DNS rebinding 和 IP 直連內網？
共用 transport 面
- 路徑相關的 tool（讀檔、寫檔、附件）有沒有做路徑驗證，防止
../穿越？
老實講：靜態掃描能抓什麼、不能抓什麼
上面這份清單裡的絕大多數，都是上線前的靜態層面就能發現的：端點有沒有認證、預設值站哪一邊、Host/Origin 有沒有驗、綁的是不是 0.0.0.0。這些不需要真的被攻擊才看得到，這也是我們做 UltraProbe 一直主張的方向：在連線之前就掃，比出事之後再補便宜太多。（講清楚免得你帶著錯誤期待點進去：UltraProbe 目前掃的是 system prompt 防禦向量與網站 SEO/AEO 層級，MCP 伺服器本身的認證設定，現階段要靠上面那份清單手動走一遍。）
但靜態掃描不是萬能。像 mcp-atlassian 那種 TOCTOU rebinding，牽涉到執行期的時間差；像被注入的 tool response 誘導 agent 去做壞事，屬於執行期的行為。這些要靠執行期的防護層。誠實的答案是：靜態的上線前稽核加上執行期的防護，兩層都要，缺一層都會漏。 任何跟你說單一工具搞定一切的，你可以直接懷疑。
如果你想更系統地看 agent 的整體攻擊面，我們另外寫過 OWASP Agentic ASI Top 10 逐項拆解，MCP 這類 tool 濫用在那份清單裡也有對應的位置。
一句話帶走
MCP 正在爆發式成長，這是好事。但 2026 年 7 月這一個月告訴我們：這個生態目前的預設值，是把安全交給實作者自己記得。 在那個預設值改過來之前，接上任何一個 MCP 伺服器之前，請自己先把上面那份清單走一遍。連官方 SDK 都會中，你的供應鏈沒有理由假設自己不會。
本文所有漏洞資訊均對 GitHub Advisory Database 第一手查證，資料截至 2026-07-24。