跳到正文
DEV Community· razashariff·· 3 小時前精選AI 評分78

無限制請求正文如何在各主要 MCP SDK 中形成拒絕服務漏洞類別

The first of its kind: how one unbounded request body became a denial-of-service class across every major MCP SDK

AI 導讀

CVE-2026-39313 揭示，MCP HTTP 傳輸中未限制大小的請求正文可在無需驗證下耗盡伺服器記憶體，造成拒絕服務。其後至少另外九個 MCP 專案發現相同問題，修補方式多為設定預設 4 MiB 請求正文上限。

推薦理由

文章梳理無限制請求正文漏洞如何擴散至多個 MCP SDK，並指出核心 SDK 的漏洞通報未進入常用掃描資料庫，令直接核對版本成為必要防護環節。

正文 · 繁體中文

一行版

2026年4月，我通報了 CVE-2026-39313，這是 MCP 伺服器框架中的拒絕服務漏洞。這是同類漏洞中的首個 CVE：HTTP 請求本文沒有大小限制（CWE-770），單一未經驗證的請求便可耗盡 Model Context Protocol 伺服器的記憶體，令伺服器停擺。

在接下來六個月，同一漏洞在至少另外九個 MCP 專案中被發現並修補，包括官方的 Python、Java、Go、Ruby、PHP 和 TypeScript SDK。7月，一份第三方分析稱之為「一種新的漏洞類別」。到了10月，其中兩個 CVE 出現在整個生態系統賴以建立的 SDK 中，這些 SDK 每月合計下載量接近5億次。

本文記述這類漏洞的經過：它如何擴散、哪些項目已修補、哪些仍然暴露於風險之中，以及為何最嚴重的兩個漏洞幾乎逃過大部分團隊倚賴的掃描器。

下文每項説法均連結至一手來源。

漏洞的實際運作方式

MCP 伺服器透過 HTTP 傳輸機制通訊：Streamable HTTP、Server-Sent Events，以及 OAuth 路由。為處理請求，伺服器會先將請求本文讀入記憶體，之後才進行其他操作。

這個漏洞既簡單又嚴重。讀取迴圈沒有大小限制，會不斷將資料塊附加到緩衝區，直至客戶端停止傳送或程序終止。前面沒有任何驗證機制，因為在執行任何驗證檢查之前就會讀取本文。因此，攻擊者只要能連接到端點，便可傳送一個大型 POST 請求，或持續緩慢傳送資料，令伺服器不斷分配記憶體，直至 OOM reaper 終止程序。一個請求，就能令伺服器停擺，而且不需要任何憑證。

這是 CWE-770：在沒有上限的情況下分配資源。這並非甚麼罕見問題，也正因如此，它才會在各處出現。

CVE-2026-39313：首個漏洞

這類漏洞首份公開安全公告涉及 mcp-framework，這是一個廣受歡迎、用於建立 MCP 伺服器的 TypeScript 框架。

在 0.2.21 及以下版本中，HTTP 傳輸機制的 readRequestBody() 函式會將各段本文串接成字串，且沒有大小上限。框架甚至設有 maxMessageSize 設定值，但 readRequestBody() 從未引用該值。這個上限只存在於文件中，程式碼從未實際執行限制。向 /mcp 傳送單一大型 POST 請求便會令伺服器當機。

我提交了報告，問題在 0.2.22 版本修復，安全公告於 2026年4月16日發布。

當時看來只是某個框架的失誤。事實並非如此。

這不是單一漏洞，而是一種模式。

以下是 2026 年期間，同一種請求本文無大小限制的拒絕服務漏洞如何在 MCP 生態系統各處出現，以及相關安全公告和修補程式陸續推出的時間線：

  • 4月16日 — mcp-framework，CVE-2026-39313（首個漏洞）。
  • 4月至6月 — Google 的 MCP Toolbox for Databases 出現相同的 io.ReadAll，且沒有大小限制；該問題在我的安全公告發布四天後被舉報，並於6月修復。沒有安全公告，也沒有 CVE。
  • 7月 — 官方 Go SDK 加入請求本文大小上限，並在版本説明中以 OOM 防護項目推出；沒有安全公告，也沒有 CVE。
  • 7月30日 — Ruby SDK，CVE-2026-67432。一個 512 MB 的 POST 請求令工作程序的記憶體用量由 44 MB 增至 1.66 GB。修補方式是設置 4 MiB 的預設上限。
  • 8月19日 — PHP SDK，CVE-2026-53965，客戶端版本：SSE 緩衝區沒有大小上限。Java SDK 同日發布了相應的客戶端 SSE 修正。
  • 9月16日 — Rust SDK rmcp，CVE-2026-63128。
  • 10月11日 — mcp-go，CVE-2026-108859。
  • 10月14日 — 官方 Python SDK，CVE-2026-109527，以及官方 Java SDK，CVE-2026-108395。兩項漏洞的報告者名單中都有我的名字。
  • 10月20日及27日 — 官方 TypeScript SDK，CVE-2026-111768 及一份後續安全公告。

九個以上的獨立專案。同一個根本原因。每次修正都一模一樣：設定預設本文大小上限，幾乎總是 4 MiB。

7月的一篇獨立文章探討了這個問題，並稱 CVE-2026-39313 是針對 MCP HTTP 傳輸機制首宗有記錄的拒絕服務攻擊，也是「一種新的漏洞類別」。這個説法切中要點。這並非一連串互不相關的漏洞，而是 MCP 傳輸機制讀取輸入資料時的一個設計缺陷，在協定支援的每種語言中都重複出現。

承載協定的兩個 SDK

這類漏洞大多出現在框架和綁定程式庫中，但有兩個例外。它們位於參考 SDK 中，而幾乎每個 MCP 部署都會匯入這些 SDK。

CVE-2026-109527，官方 Python SDK（mcp）。在 1.29.1 之前的版本，以及截至 2.0.1 的 2.0 預發佈版本中，Streamable HTTP 工作階段管理器、SSE 訊息端點和 OAuth 授權伺服器路由都會緩衝完整的請求本文，卻沒有設定大小上限。未經驗證的遠端用戶可以傳送一個已聲明大小很大或以串流方式傳送的本文，令程序記憶體用量增至該本文大小的數倍，並不斷重複這個操作，直至伺服器停止運作。

CVE-2026-108395，官方 Java SDK。mcp-core HTTP 伺服器傳輸機制讀取請求本文時沒有大小上限，屬於同一類漏洞，影響也相同。

以規模而言：官方 TypeScript SDK 每月下載量約為 257 million 次，Python SDK 則為 235 million 次。當漏洞位於 SDK，而非單一伺服器中，任何以該 SDK 建置的伺服器只要提供 HTTP 傳輸機制，就會受到影響。

哪些已修補，哪些仍受影響

Red Hat 將 CVE-2026-109527 評為重要，評估了 44 款產品，並發布了三份勘誤公告：

  • RHSA-2026:92510（OpenShift AI 3.4）、RHSA-2026:92666 和 RHSA-2026:92667（Satellite 6.19 和 6.18）。
  • 在評估的 44 款產品中，35 款受影響、6 款不受影響，另有 3 款標記為不會修復。
  • https://access.redhat.com/security/cve/CVE-2026-109527

Debian 也追蹤了影響 python-mcp 的同一項 CVE，嚴重程度為嚴重；截至本文撰寫時，unstable 版本中的套件仍未修正。

下游產品在 10 月陸續升級固定的依賴版本：OpenMetadata 已合併升級，Red Hat 的 Open Data Hub 開始提交修正 PR，而相關安全公告發布以來，GitHub 上已有數百個自動化的「bump mcp」拉取請求獲得合併。

有安全團隊的認真營運者正在採取行動。問題是，其他人呢？

規格仍未要求這項內容

儘管已經發布多項修補，根本原因在設計層面上始終未獲解決。截至 2026 年 11 月上旬，MCP 安全最佳實務文件仍未就請求本文大小限制提供指引。每個 SDK 都自行解決這個問題，並採用各自的預設值，因為規格從未作出規定。這就是為甚麼同一項修正必須被反覆重新發現六次、七次、八次。

現有的 MCP 伺服器安全指引，包括美國國家安全局及 CISA 的 MCP 資訊單張，雖然將資源耗盡型阻斷服務攻擊列為一般風險，卻沒有為實作者指出任何具體的防護措施。唯一能在設計層面阻止整類問題的地方，至今仍未提及此事。

盲點：大多數掃描器看不到最嚴重的兩個漏洞

截至 2026 年 11 月 3 日的情況是如此；資料庫一旦補上資料，情況可能當天就會改變。請自行查證。

npm 那項漏洞 CVE-2026-39313 有完整的全球 GitHub 安全公告。OSV 有收錄，npm audit 也有收錄，掃描有漏洞的專案時亦會標示出來。

兩項 SDK CVE 的情況並不相同。CVE-2026-109527 和 CVE-2026-108395 只以儲存庫層級公告的形式存在於 Python 和 Java SDK 專案中。它們從未納入全球 GitHub Advisory Database。造成的連鎖影響是一連串盲點：

  • 全球 GitHub 安全公告鏡像資料庫沒有收錄這兩項漏洞，因此 GitHub Dependabot 不會就此發出警示。
  • OSV 也沒有收錄，因此 osv-scanner 及所有建基於 OSV 的工具都會漏掉這兩項漏洞。查詢有漏洞的 mcp 版本時，會顯示其他 2026 年 CVE，卻不會顯示這項漏洞。
  • PyPA 安全公告資料庫沒有相關記錄，因此 pip-audit 查不到任何結果。
  • NVD 將兩項漏洞都列為「等待分析」，但沒有版本資料，因此即使是以 NVD 為依據的掃描器，也沒有可供比對的版本範圍。

實際結果是：運行有漏洞的 mcp 套件的伺服器，即使經 pip-audit、osv-scanner、Dependabot，或一款包裝 pip-audit 的熱門 MCP 專用掃描器掃描，仍可能被判定沒有這項阻斷服務漏洞。修補程式已推出，安全公告亦已撰寫，但本應提醒用戶的機器可讀資料管道，卻從未傳遞這項資訊。

Red Hat、Debian 和 SUSE 等企業級發行版的漏洞追蹤系統有收錄這項漏洞，因為它們會從自己的 CNA 和 NVD 資訊來源取得資料。Red Hat 甚至為此發布了機器可讀的 VEX 檔案。但大多數團隊實際使用的開發者供應鏈工具卻沒有收錄。如果你依賴 pip-audit 或 Dependabot 通知你相關漏洞，目前它們不會通知你。

攻擊者能做甚麼，以及誰面臨風險

如果你運行的 MCP 伺服器符合以下條件，便會面臨風險：

  • 提供基於 HTTP 的傳輸方式（Streamable HTTP 或 SSE），而非只使用 stdio；而且
  • 可由任何你無法完全信任的用戶端存取，包括公眾互聯網、共用的內部網絡，或瀏覽器可存取的來源；而且
  • 使用下列框架或 SDK 的易受攻擊版本。

這項攻擊不需要驗證、認證資料或用戶操作。一個過大的或無限長的請求便會令程序崩潰。重複發送，服務便會持續停擺。攻擊者輕易便可編寫腳本自動發動。這不涉及資料竊取，影響純粹在於可用性；但對於其他系統所依賴的 Agent 後端，能按需令其離線，便是攻擊的全部目的。

僅使用 stdio 的伺服器，以及已部署在設有自身請求本文大小限制的反向代理後方的服務，不會以相同方式暴露於風險。修補期間，該代理的限制也是最快的緩解措施。

修補方案

請升級。已修復問題的版本如下：

  • mcp-framework（npm）：0.2.22 或以上。
  • MCP Python SDK（PyPI 上的 mcp）：1.29.1 或以上。修正方案在傳輸安全層加入 max_request_body_size，並將 DEFAULT_MAX_REQUEST_BODY_SIZE 設為 4 MiB。
  • MCP Java SDK：已修補的 mcp-core 版本。
  • MCP Go SDK：v1.7.0 或以上，會強制將 DefaultMaxRequestBodyBytes 限制為 4 MiB。
  • Ruby SDK（mcp gem）：0.23.0 或以上。
  • PHP SDK、Rust rmcp、mcp-go、TypeScript SDK：升級至最新版本；這些 SDK 均在秋季期間加入了相同的本文大小上限。

如果你未能立即升級，可在前方設定反向代理並限制用戶端請求本文大小（例如 nginx client_max_body_size），同時確保不可信任網絡無法連接你的 HTTP 傳輸層。如果你的 SDK 提供可設定的限制，請明確設定，而不要依賴預設值；如果你確實需要處理大型負載，尤其要這樣做。

如何在你的部署環境中找出受影響項目

  • 盤點你運行的每個 MCP 伺服器，並確認它提供的是 HTTP 傳輸，還是隻支援 stdio。
  • 就這個問題而言，目前不要只依賴 pip-audit。直接檢查已安裝的 mcp 版本：任何低於 1.29.1 的版本都存在漏洞。
  • 對於 npm，npm audit 可以找出低於 0.2.22 的 mcp-framework。
  • 對於 Java 和 Go，請對照上文列出的已修補版本檢查 SDK 版本，因為目前全球資料庫尚未收錄相關安全公告，而你的 SCA 工具會讀取這些資料庫。
  • 在你自己的 HTTP 處理程式中搜尋這種寫法：讀取本文時沒有長度上限、Go 中的 io.ReadAll(r.Body)、Ruby 中沒有上限的 request.body.read，以及 Node 中在任何大小檢查之前執行的 string += 分塊迴圈。如果你自行編寫自訂傳輸層，也可能重現了這類漏洞。

教訓

MCP 生態系統的發展速度超越了其安全指引。傳輸層讀取輸入時的一個疏漏，演變成影響該協定所有主要 SDK 的阻斷服務漏洞，而防止這類問題的唯一控制措施仍未寫入規格。

目前已有修正方案，但規格中的相關指引仍未補上。至於核心 SDK 中的兩個 CVE，截至今天，我們所依賴的自動警示系統仍未發出警示。如果你在正式環境中運行 MCP，不要等掃描器提醒你，請自行檢查版本。

參考資料

Raza Sharif（CyberSecAI Ltd.）通報了 CVE-2026-39313，並因 CVE-2026-109527 和 CVE-2026-108395 獲得致謝。所有漏洞均透過協調披露流程處理，並已在上述版本中修復。聯絡方式：contact@agentsign.dev。

來源：DEV Community · dev.to

#現象/趨勢#MCP/工具調用