plaincve:~$

// 威脅簡報

CVE-2026-109527

MCP Python SDK 請求內容沒有大小上限:一個超大請求就能耗盡伺服器記憶體

CVSS
7.5 HIGH
CISA KEV
未列入
弱點類型
CWE-770
主題
AI 安全 · Web 應用

PlainCVE 團隊 · 發布 2026-10-19 · AI 輔助 · 媒體簡報 ↓

AI 審稿 2026-10-19(未經人工)指令測試:未提供漏洞重現:未進行驗證紀錄 ↓

MCP 官方 Python SDK 的 HTTP 伺服器端點讀取請求內容時沒有大小上限,連得到伺服器的用戶端可以反覆耗盡記憶體、讓服務停擺。

誰會中使用 pip 套件 mcp 早於 1.29.1(不含 1.29.1)或 2.0.x 版本、以 HTTP 傳輸(Streamable HTTP、SSE)或內建 OAuth 授權端點對外提供服務,且不完全信任的用戶端能透過 HTTP 連到、前方沒有已限制請求大小的反向代理或閘道的 MCP 伺服器。只用 stdio 的伺服器與 MCP 用戶端不受影響。
後果阻斷服務:單一超大請求會讓伺服器程序的記憶體增加約請求內容的 2 到 3 倍,可反覆讓伺服器耗盡記憶體或終止。CVSS 評分沒有機密性與完整性影響。
現在該做什麼升級到 mcp 1.29.1(1.x)或 2.1.0(2.x)以上;2.0.x 沒有修補版。暫時無法升級時,在反向代理或 ASGI 中介層限制請求內容大小。
受影響版本早於 1.29.1(不含 1.29.1)的所有版本;2.x 方面,官方公告列 2.0.0 至 2.0.1,CVE 紀錄另含 2.0.0a1 起的預發布版本(來源不一致)
修好的版本1.29.1 以上(1.x)、2.1.0 以上(2.x);沒有 2.0.x 修補版
CVSS 向量
顯示完整向量CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
時間點
  • 首次公開 2026-09-30

藍隊應對手冊

確認、修補 / 緩解、應變、強化。版本符合受影響條件不等於已被入侵;檢查沒有結果也不等於安全,每一項都有能證明與不能證明的範圍。標記的步驟對應下方攻擊流程裡可以擋下攻擊的那一步。

DETECT確認我受影響嗎?有沒有入侵跡象?
  1. 01確認 mcp 版本與曝險條件

    在執行 MCP 伺服器的那個 Python 環境(例如它使用的虛擬環境)裡執行這個唯讀指令;在別的環境執行,查到的可能不是伺服器實際使用的版本。以下條件同時成立才受影響:mcp 早於 1.29.1(不含 1.29.1)或 2.0.x、伺服器使用 HTTP 傳輸或內建 OAuth 端點、不完全信任的用戶端連得到它、前方沒有已限制請求大小的反向代理。只用 stdio 的伺服器與 MCP 用戶端不受影響。

    唯讀查詢
    python -m pip show mcp | grep -i '^version'
  2. 02留意直接使用 StreamableHTTPServerTransport 的程式

    官方說明:不透過工作階段管理器、直接驅動 StreamableHTTPServerTransport 的程式,升級後也拿不到這個上限,必須自行限制請求大小。指令是唯讀搜尋,請在你自己的專案原始碼根目錄執行。

    唯讀查詢
    grep -rn "StreamableHTTPServerTransport" --include='*.py' .
    步驟 2
MITIGATE修補 / 緩解先修補;還不能修補時先擋住
  1. 011.x 使用者:升級到 1.29.1 以上(仍留在 1.x)

    這個指令會修改環境(安裝新版套件),請在執行 MCP 伺服器的那個 Python 環境(例如它使用的虛擬環境)裡執行。修補後 SDK 內建的伺服器應用與工作階段管理器共用一個請求大小上限(預設 4 MiB)。1.29.0 只修了 Streamable HTTP,SSE 與 OAuth 端點仍無上限,不算完整修補。

    會變更環境
    python -m pip install -U "mcp>=1.29.1,<2"
    步驟 2步驟 3
  2. 022.x 使用者:升級到 2.1.0 以上

    這個指令會修改環境(安裝新版套件),請在執行 MCP 伺服器的那個 Python 環境(例如它使用的虛擬環境)裡執行。沒有 2.0.x 修補版;2.0.0 只修了 Streamable HTTP,不算完整修補。1.x 使用者不要用這個指令,否則會跨大版本升到 2.x。

    會變更環境
    python -m pip install -U "mcp>=2.1.0"
    步驟 2步驟 3
  3. 03還不能升級:在前方限制請求大小

    官方建議:在伺服器前方的反向代理或 ASGI 中介層限制請求內容大小。

    步驟 1步驟 2
RESPOND應變發現入侵跡象時
  1. 01升級後觀察被拒絕的超大請求(HTTP 413)

    這是 PlainCVE 的建議與寫法(唯讀)。請在你自己的反向代理主機上執行;指令假設是 nginx 且紀錄放在 /var/log/nginx,會搜尋該資料夾與子資料夾裡所有存取紀錄,包含輪替與 .gz 壓縮的舊檔,路徑不同請自行調整。注意:這只能找出升級後被拒絕、回應 413 的請求;修補前的超大請求不會回 413,存取紀錄預設格式也不一定記錄請求內容大小,所以它查不出過去停擺當時的請求。服務曾因記憶體耗盡停擺時,請另外對照該時段打到 MCP 的 HTTP 或 OAuth 端點的請求與伺服器的記憶體紀錄。本漏洞的影響僅限可用性。

    唯讀查詢
    find /var/log/nginx -type f -name '*access*' -exec zgrep -H '" 413 ' {} +
    步驟 3步驟 4
HARDEN強化長期避免同類問題
  1. 01MCP 伺服器不要直接面對不受信任的用戶端

    在前方放置會限制請求大小的反向代理或閘道,即使未來出現類似問題也多一層保護。

    步驟 1
  2. 02只在必要時調高上限

    官方說明:若用戶端確實會送出超過 4 MiB 的單一訊息,可用 max_request_body_size 參數調高上限。PlainCVE 建議:不要直接關掉限制。

    步驟 2
完整修復步驟與說明
你目前的版本升級到
1.x(早於 1.29.1,含 1.29.0)1.29.1 以上,例如 pip install -U "mcp>=1.29.1,<2"
2.0.x(含預發布版本)2.1.0 以上,例如 pip install -U "mcp>=2.1.0";沒有 2.0.x 修補版
  • 1.29.0 與 2.0.0 不夠。 它們只保護 Streamable HTTP,SSE 與 OAuth 端點仍沒有上限。
  • 升級後仍要自己處理的情況。 如果程式直接使用 StreamableHTTPServerTransport 而沒有透過工作階段管理器,不會套用這個上限,必須自行限制請求大小。
  • 合法的大訊息。 若用戶端確實會送出超過 4 MiB 的單一訊息,官方建議用 max_request_body_size 參數調高上限;2.1.0 發布說明提到 SseServerTransport 與 MCPServer.sse_app() 也接受這個參數。同一版本的 SSE 訊息端點也會對非 POST 請求回應 405。
  • 暫時無法升級。 官方建議在伺服器前方的反向代理或 ASGI 中介層(包在 Python 網頁應用外層、先處理請求的程式)限制請求大小。

攻擊流程

從左到右是攻擊發生的順序。藍色盾牌代表這一步可以被擋下,越早擋下越好。點圖示可看細節。

由上到下是攻擊發生的順序。藍色盾牌代表這一步可以被擋下,越早擋下越好。點圖示可看細節。

MCP Python SDK 請求內容沒有大小上限:一個超大請求就能耗盡伺服器記憶體: 1. 對 MCP 伺服器的 HTTP 端點送出內容極大的請求 → 2. 伺服器先把整個請求內容讀進記憶體,才檢查大小 → 3. 記憶體用量暴增 → 4. 伺服器記憶體耗盡而停擺,且可反覆發生CVE-2026-109527 · MCP Python SDK 請求內容沒有大小上限:一個超大請求就能耗盡伺服器記憶體攻擊者你的系統對 MCP 伺服器的 HTTP 端點送出內容極大的請求 — 受影響的是 Streamable HTTP 工作階段管理器、SSE 訊息端點與 OAuth 授權端點。對 OAuth 端點,或對不要求認證的伺服器(預設設定),不需要任何憑證。 1對 MCP 伺服器的HTTP 端點送出內容極大的請求伺服器先把整個請求內容讀進記憶體,才檢查大小 — 官方公告指出,舊版先把整個請求內容讀進記憶體才檢查大小;1.29.0、2.0.0 起 Streamable HTTP 已有 4 MiB 上限,SSE 訊息端點與 OAuth 端點則完全沒有上限,直到 1.29.1、2.1.0。 2伺服器先把整個請求內容讀進記憶體,才檢查大小記憶體用量暴增 — 官方公告指出,單一大請求會讓程序記憶體增加約內容大小的 2 到 3 倍。 3記憶體用量暴增伺服器記憶體耗盡而停擺,且可反覆發生 — 影響僅限可用性;沒有來源提到程式碼執行或資料外洩。 4伺服器記憶體耗盡而停擺,且可反覆發生攻擊路徑可在此擋下PlainCVE · plaincve.date/vulns/cve-2026-109527-mcp-python-sdk-body-size-dos · CC BY 4.0
MCP Python SDK 請求內容沒有大小上限:一個超大請求就能耗盡伺服器記憶體: 1. 對 MCP 伺服器的 HTTP 端點送出內容極大的請求 → 2. 伺服器先把整個請求內容讀進記憶體,才檢查大小 → 3. 記憶體用量暴增 → 4. 伺服器記憶體耗盡而停擺,且可反覆發生CVE-2026-109527 · MCP Python SDK 請求內容沒有大小上限:一個超大請求就能耗盡伺服器記憶體對 MCP 伺服器的 HTTP 端點送出內容極大的請求 — 受影響的是 Streamable HTTP 工作階段管理器、SSE 訊息端點與 OAuth 授權端點。對 OAuth 端點,或對不要求認證的伺服器(預設設定),不需要任何憑證。 1攻擊者對 MCP 伺服器的 HTTP 端點送出內容極大的請求伺服器先把整個請求內容讀進記憶體,才檢查大小 — 官方公告指出,舊版先把整個請求內容讀進記憶體才檢查大小;1.29.0、2.0.0 起 Streamable HTTP 已有 4 MiB 上限,SSE 訊息端點與 OAuth 端點則完全沒有上限,直到 1.29.1、2.1.0。 2你的系統伺服器先把整個請求內容讀進記憶體,才檢查大小記憶體用量暴增 — 官方公告指出,單一大請求會讓程序記憶體增加約內容大小的 2 到 3 倍。 3你的系統記憶體用量暴增伺服器記憶體耗盡而停擺,且可反覆發生 — 影響僅限可用性;沒有來源提到程式碼執行或資料外洩。 4你的系統伺服器記憶體耗盡而停擺,且可反覆發生攻擊路徑可在此擋下PlainCVE · CC BY 4.0plaincve.date/vulns/cve-2026-109527-mcp-python-sdk-body-size-dos
圖片可自由用於報導與教學,採 CC BY 4.0,圖上已附出處。
  1. 攻擊者

    對 MCP 伺服器的 HTTP 端點送出內容極大的請求

    受影響的是 Streamable HTTP 工作階段管理器、SSE 訊息端點與 OAuth 授權端點。對 OAuth 端點,或對不要求認證的伺服器(預設設定),不需要任何憑證。

    防禦: 不要讓不完全信任的用戶端直接連到伺服器;在前方放置會限制請求大小的反向代理或閘道。

  2. 你的系統

    伺服器先把整個請求內容讀進記憶體,才檢查大小

    官方公告指出,舊版先把整個請求內容讀進記憶體才檢查大小;1.29.0、2.0.0 起 Streamable HTTP 已有 4 MiB 上限,SSE 訊息端點與 OAuth 端點則完全沒有上限,直到 1.29.1、2.1.0。

    防禦: 升級到 1.29.1 或 2.1.0 以上:超過上限(預設 4 MiB)的請求會在解析前直接回 HTTP 413。

  3. 你的系統

    記憶體用量暴增

    官方公告指出,單一大請求會讓程序記憶體增加約內容大小的 2 到 3 倍。

    防禦: 還不能升級時,用 ASGI 中介層限制請求內容大小。

  4. 你的系統

    伺服器記憶體耗盡而停擺,且可反覆發生

    影響僅限可用性;沒有來源提到程式碼執行或資料外洩。

影響範圍

受影響的是 MCP(Model Context Protocol,讓 AI 呼叫外部工具的通訊協定)官方 Python SDK,也就是 pip 套件 mcp,而且只有伺服器端。

條件是否受影響
mcp 早於 1.29.1(1.x,不含 1.29.1)受影響(1.29.0 只修了 Streamable HTTP,不完整)
mcp 2.0.0、2.0.1受影響(2.0.0 只修了 Streamable HTTP,不完整)
mcp 2.0.0a1 起的 alpha、beta、rc 預發布版本來源不一致:CVE 紀錄與 OSV 列為受影響,官方公告的範圍從 2.0.0 起算、未提及預發布版本
mcp 1.29.1 以上、2.1.0 以上已修補
只使用 stdio 傳輸的伺服器不受影響
用 SDK 寫的 MCP 用戶端不受影響
前方已有限制請求大小的反向代理(擋在伺服器前方、先接收請求的服務)或閘道不受影響

官方的說法是:如果不完全信任的用戶端能透過 HTTP 連到你的伺服器,就需要處理。對 OAuth 端點,或對不要求認證的伺服器(這是預設),攻擊者不需要任何憑證。要求認證的伺服器,其 Streamable HTTP 與 SSE 端點能否在沒有憑證下被攻擊,官方公告沒有說明。

原理

SDK 內建三種 HTTP 入口:Streamable HTTP 工作階段管理器、SSE 訊息端點,以及 OAuth 授權伺服器的路由(/token、/register、/revoke、/authorize)。舊版在這些入口收到請求時,會先把整個請求內容(body)讀進記憶體,才檢查大小(官方公告的說法)。1.29.0 與 2.0.0 起,Streamable HTTP 已有 4 MiB 上限;SSE 訊息端點與 OAuth 路由則完全沒有上限,直到 1.29.1 與 2.1.0。

官方公告指出,單一大請求會讓伺服器程序的記憶體增加約內容大小的 2 到 3 倍。連得到伺服器的用戶端因此可以耗盡記憶體、讓伺服器停擺,而且可以一再重來。這類錯誤對應 CWE-770(資源配置沒有上限或節流)。CVSS 評分只有可用性影響,沒有機密性與完整性影響;沒有來源提到程式碼執行或資料外洩。

有問題的思路(概念示意,不是原始程式碼):

展開程式碼範例(python)
body = await read_entire_body(request)   # 先全部讀進記憶體,之後才看大小
message = parse(body)

修好的思路:

展開程式碼範例(python)
body = await read_body_with_limit(request, max_size=4 * 1024 * 1024)
# 宣告或實際串流的大小一超過上限,就在解析前回應 413
message = parse(body)

修補分兩階段:1.29.0 與 2.0.0 先替 Streamable HTTP 加上 4 MiB 上限;1.29.1 與 2.1.0 才把同一個上限延伸到 SSE 訊息端點與 OAuth 路由。

時間軸

日期事件
2026-07-14專案公開 PR #3095(該頁含攻擊程式,本站不連結;修補 commit 為 03aaebd),替 Streamable HTTP 加上請求內容上限(max_request_body_size,超過回 413)。2026-07-15 一則由 claude[bot] 發出的自動審查留言(機器人留言,不是官方的資安揭露或安全公告)指出 SSE 的 POST 端點仍無上限地讀完整個請求內容,是「the same DoS vector this PR closes」。這則留言只講到 SSE 端點,沒有提到 OAuth 授權端點,也沒有提到記憶體增加約 2 到 3 倍的放大倍數;因此本站的首次公開日仍採 2026-09-30 的安全公告
2026-07-16PR #3095 合併
2026-08-19專案公開 PR #3336(修補 commit 為 57394b0),把同一個上限延伸到 SSE 訊息端點與 OAuth 路由(08-20 合併)
2026-08-24依 PyPI 的上傳紀錄(1.29.1、2.1.0),v1.29.1 與 v2.1.0 發布,修補 SDK 內建的伺服器應用與工作階段管理器;比安全公告早約五週
2026-09-30官方 GitHub 安全公告 GHSA-fmmv-w9g8-j3gc 公開
2026-10-12CVE 編號保留
2026-10-14CVE 紀錄公開
2026-10-15依 PlainCVE 的 KEV 快照,尚未列入 CISA 已知遭利用漏洞清單

延伸閱讀

  • 評分: CNA(GitHub)給 CVSS 3.1 7.5,向量 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H,與官方公告一致。截至 2026-10-19 查詢,NVD 狀態為「Awaiting Analysis」(最後修改 2026-10-16),NVD 自己尚未評分;NVD 頁面上顯示的 7.5 是 CNA(security-advisories@github.com)提供的 Secondary 分數,不是 NVD 的評分。
  • 受影響的 2.x 範圍不一致: 官方公告寫 2.0.0 以上、2.1.0 以前;CVE 紀錄寫從 2.0.0a1 起,OSV 也列出 v2.0.0b1、v2.0.0b2、v2.0.0rc1。保守起見,把所有 2.0.x 預發布版本都當成受影響。
  • 漏洞從何時開始: 沒有來源指出引入問題的提交。OSV 的範圍起點標為「0」(沒有已知起點);PlainCVE 的判斷是,這些 HTTP 端點可能從早期版本起就沒有大小上限。
  • 利用狀況: 截至 2026-10-15 未列入 CISA KEV。是否已遭實際利用、是否曾是零時差,來源都沒有說明。專案公開的 PR #3095 有一則 claude[bot] 的自動審查留言寫了對 SSE 訊息端點重現記憶體耗盡的步驟(該頁含攻擊程式,本站不連結);除此之外,沒有來源提到公開的概念驗證程式。
  • 資料庫狀態: 在本次快照中,以 CVE 編號查詢 GitHub Advisory Database API 回傳空結果,但專案的安全公告本身存在。
  • 致謝: 官方公告感謝 GitHub 使用者 razashariff 與 shmulc8 回報。
  • 相關弱點類型:CWE-770。修補提交:1.x 為 5f0b6af(#3101)、4dc224f;2.x 為 03aaebd(#3095)、57394b0(#3336)。

驗證紀錄 AI 依審稿規則逐項核對來源,全部通過;未經人工審稿,也尚未在我們的環境重現

AI 審稿2026-10-19 · 審稿規則

驗證紀錄只寫環境與結果,不公開重現步驟或可攻擊他人系統的程式。詳見 政策.

來源

  1. 安全公告GHSA-fmmv-w9g8-j3gc — MCP Python SDK request body size limit · Model Context Protocol (GitHub), 2026-09-30 · 查閱 2026-10-15
  2. CVE / NVD / OSVCVE-2026-109527 Record (CVE Services API) · CVE Program, 2026-10-14 · 查閱 2026-10-15
  3. CVE / NVD / OSVNVD API - CVE-2026-109527 · NIST · 查閱 2026-10-15
  4. 修補 commit / 版本[v1.x] Add Streamable HTTP request body limits (#3101) · Model Context Protocol (GitHub) · 查閱 2026-10-15
  5. 修補 commit / 版本[v1.x] Apply the request body limit to the SSE and OAuth endpoints · Model Context Protocol (GitHub) · 查閱 2026-10-15
  6. 修補 commit / 版本Add Streamable HTTP request body limits (#3095) · Model Context Protocol (GitHub) · 查閱 2026-10-15
  7. 修補 commit / 版本Apply the request body limit to the SSE and OAuth endpoints (#3336) · Model Context Protocol (GitHub) · 查閱 2026-10-15
  8. 修補 commit / 版本mcp v1.29.1 release · Model Context Protocol (GitHub) · 查閱 2026-10-15
  9. 修補 commit / 版本mcp v2.1.0 release · Model Context Protocol (GitHub) · 查閱 2026-10-15
  10. 其他PyPI JSON API - mcp 1.29.1 · PyPI · 查閱 2026-10-15
  11. 其他PyPI JSON API - mcp 2.1.0 · PyPI · 查閱 2026-10-15
  12. 其他OSV - CVE-2026-109527 · OSV · 查閱 2026-10-15
  13. 其他GitHub Advisory Database API query for CVE-2026-109527 · GitHub · 查閱 2026-10-15

媒體簡報

一句話

MCP(Model Context Protocol)是讓 AI 呼叫外部工具的通訊協定,它的官方 Python SDK 在 HTTP 伺服器端點讀取請求時沒有大小上限。連得到伺服器的用戶端只要送出超大請求,就可能反覆耗盡記憶體、讓服務停擺。專案在 1.29.1 與 2.1.0(2026 年 8 月 24 日發布)完成 SDK 內建伺服器的修補,並於 2026 年 9 月 30 日公開安全公告。截至 2026 年 10 月 15 日,它不在美國 CISA 的已知遭利用漏洞清單上。

關鍵數字

嚴重度
CVSS 3.1 7.5(CNA 提供;NVD 截至 2026-10-19 為 Awaiting Analysis,尚未自行評分) cveawg.mitre.org
修補版本
1.29.1(1.x)、2.1.0(2.x) github.com
首次公開
2026-09-30(GHSA-fmmv-w9g8-j3gc 公開日,早於 CVE 紀錄的 2026-10-14) github.com
安全公告公開
2026-09-30(GHSA-fmmv-w9g8-j3gc) github.com
CVE 公開
2026-10-14 cveawg.mitre.org
回報者
GitHub 使用者 razashariff、shmulc8 github.com

已確認

  • Streamable HTTP、SSE 訊息端點與 OAuth 授權端點讀取請求內容時沒有大小上限。
  • 影響是阻斷服務:可反覆耗盡記憶體讓伺服器停擺;CVSS 評分沒有機密性或完整性影響。
  • 1.29.1 與 2.1.0 修補了 SDK 內建的伺服器應用與工作階段管理器;直接使用 StreamableHTTPServerTransport 的程式升級後仍要自行限制請求大小;沒有 2.0.x 修補版。

尚未確認 / 說法不一

  • 2.0.0 的 alpha、beta、rc 預發布版本是否受影響:CVE 紀錄與 OSV 說是,官方公告沒有提到。
  • 是否已遭實際利用,來源都沒有說明。專案公開的 PR
  • 要求認證的伺服器,其 Streamable HTTP 與 SSE 端點能否在沒有憑證下被攻擊,官方公告沒有說明。

可引用的一句話

伺服器不問訪客帶了多大的包裹就全收進倉庫,倉庫遲早會塞爆。

圖片

下載分享圖(PNG) · 攻擊流程圖(可下載)

引用時請標示「PlainCVE」並附上本頁連結。 完整引用格式見下方「如何引用本頁」。有事實錯誤請回報.

如何引用本頁

本文採 CC BY 4.0,轉載請保留署名與連結。

PlainCVE 團隊(2026)。《MCP Python SDK 請求內容沒有大小上限:一個超大請求就能耗盡伺服器記憶體》。PlainCVE。https://plaincve.date/vulns/cve-2026-109527-mcp-python-sdk-body-size-dos(查閱日期:YYYY-MM-DD)
BibTeX
@misc{cve2026109527mcppythonsdkbodysizedos2026,
  title  = {MCP Python SDK 請求內容沒有大小上限:一個超大請求就能耗盡伺服器記憶體},
  author = {PlainCVE 團隊},
  year   = {2026},
  howpublished = {PlainCVE},
  url    = {https://plaincve.date/vulns/cve-2026-109527-mcp-python-sdk-body-size-dos},
  note   = {更新於 2026-10-19}
}