// 威脅簡報

MCP Python SDK 工作階段無限累積:能連上有狀態 Streamable HTTP 端點的用戶端可讓伺服器記憶體一直增長

CVSS: 6.9 MEDIUM
CISA KEV: 未列入
弱點類型: CWE-400 · CWE-770 · CWE-772
主題: AI 安全

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

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

MCP Python SDK 舊版(1.8.0–1.29.1、2.0.0–2.1.1)的有狀態 Streamable HTTP 伺服器不會清掉舊的工作階段,能連上端點的用戶端可讓記憶體無上限增長,只有重啟才能回收。

誰會中	使用 PyPI 套件 mcp 1.8.0 至 1.29.1 或 2.0.0 至 2.1.1、以有狀態模式(預設)提供 Streamable HTTP,且不完全信任的用戶端連得到端點的伺服器。只用 stdio 或 SSE 傳輸,或在 1.12.0 以上設定 stateless_http=True 的伺服器不受影響。
後果	伺服器記憶體可能一直增長到服務無法使用(阻斷服務),只有重啟程序才能回收。依 CVE 紀錄的評分,不影響資料的機密性或完整性。
現在該做什麼	升級 mcp 到 1.30.0(1.x)或 2.2.0(2.x)以上。暫時無法升級時,不需要每個工作階段狀態的地方改用 stateless_http=True(1.12.0 以上),或限制誰能連到端點。
受影響版本	1.8.0 至 1.29.1;2.0.0 至 2.1.1(僅限有狀態模式的 Streamable HTTP 伺服器)
修好的版本	1.30.0 以上(1.x);2.2.0 以上(2.x)
CVSS 向量	顯示完整向量 `CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N`
時間點	首次公開 2026-09-30

藍隊應對手冊

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

DETECT確認我受影響嗎?有沒有入侵跡象?

01確認版本
在執行 MCP 伺服器的主機上,先啟用該伺服器實際使用的虛擬環境(或進入它的容器)再執行,否則可能查到別的 Python 環境的版本。只讀取版本,不修改環境。mcp 1.8.0 至 1.29.1 或 2.0.0 至 2.1.1 屬於受影響範圍。
唯讀查詢
```
pip show mcp | grep -i '^version'
```
02確認是否以有狀態模式提供 Streamable HTTP
FastMCP(1.x)、MCPServer 與 Server.streamable_http_app()(2.x)以及 StreamableHTTPSessionManager 預設都是有狀態模式。只用 stdio 或 SSE 傳輸,或在 1.12.0 以上設定 stateless_http=True 的伺服器不受影響。另外要看不完全信任的用戶端是否連得到端點。請在自己 MCP 伺服器專案的原始碼根目錄執行(只讀取檔案)。直接使用 StreamableHTTPSessionManager 的程式用的參數是 stateless=,不是 stateless_http,所以兩者一起搜尋(等號前後有空格也找得到);找到時要看值是不是 True。指令排除 .venv、venv、site-packages、node_modules 與 .git,避免搜到 mcp 套件本身的原始碼或範例而誤判;虛擬環境放在其他名稱的資料夾時,請自行加上排除。PlainCVE 提醒:這個指令只是初步檢查,用環境變數或設定檔設定時搜不到,要另外確認;只用 stdio 或 SSE 傳輸的伺服器沒找到也不受影響。有提供 Streamable HTTP、又都沒找到時,才可能是使用預設的有狀態模式。
唯讀查詢
```
grep -rnE --exclude-dir=.venv --exclude-dir=venv --exclude-dir=site-packages --exclude-dir=node_modules --exclude-dir=.git "stateless(_http)?[[:space:]]*=" .
```
步驟 1
03升級後留意工作階段上限警告
2.x 修補 commit d2290ca 的文件說明,達到工作階段上限、拒絕開新工作階段時,會記錄一則 WARNING 等級的日誌「Refusing to open a new session」。1.x 移植版(PR #3426)沒有寫到這段訊息,1.30.0 是否記錄同樣的日誌未確認。經常出現可能代表有人大量開啟工作階段,也可能只是上限設得太低。請在伺服器主機上執行,把 /path/to/logs/ 換成實際存放日誌的目錄;指令會搜尋子資料夾裡的未壓縮日誌檔,只讀取檔案。PlainCVE 提醒:壓縮過的輪替檔(例如 .gz)這個指令讀不到;日誌如果只送到 stdout、journald 或容器日誌,也不在這個目錄裡,要改在那些地方查。
唯讀查詢
```
grep -rn "Refusing to open a new session" /path/to/logs/
```
步驟 2

MITIGATE修補 / 緩解先修補;還不能修補時先擋住

01目前是 1.x(1.8.0 至 1.29.1):升級到 1.30.0 以上
會修改環境:在執行 MCP 伺服器的主機上,啟用該伺服器使用的虛擬環境(或進入容器)後執行。這個指令留在 1.x,不會跨主要版本。修補版預設閒置 30 分鐘關閉工作階段、限制同時存在的數量,並在工作階段結束時立即丟棄。
會變更環境
```
pip install -U "mcp>=1.30.0,<2"
```
步驟 2 步驟 3 步驟 4
02目前是 2.x(2.0.0 至 2.1.1):升級到 2.2.0 以上
會修改環境:在執行 MCP 伺服器的主機上,啟用該伺服器使用的虛擬環境(或進入容器)後執行。只給目前已是 2.x 的使用者;PlainCVE 提醒,1.x 使用者執行這個指令會跨到 2.x 主要版本,請改用上一張卡。修補內容同上。
會變更環境
```
pip install -U "mcp>=2.2.0"
```
步驟 2 步驟 3 步驟 4
03暫時無法升級:改用無狀態模式或限制連線
官方建議:不需要每個工作階段狀態的地方設定 stateless_http=True(1.12.0 以上),或限制誰能連到端點。
步驟 1

RESPOND應變發現入侵跡象時

01記憶體異常增長時重啟並升級
維護者說明只有重啟才能回收這些記憶體。重啟只是暫時解法,之後仍要升級。目前沒有來源回報實際攻擊;第三方在正常使用下也曾觀察到工作階段無限累積,所以記憶體增長不一定代表遭攻擊。
步驟 5

HARDEN強化長期避免同類問題

01不要把 session_idle_timeout 設回 None
官方說傳入 None 會恢復舊行為。PlainCVE 的提醒:這也會讓閒置工作階段再次永不過期,只在確實必要時才這樣做。
步驟 4
02認證之外還要限制網路可達範圍
維護者指出認證只限制誰能開工作階段,不限制數量。修補後仍有殘留:每個存活中的工作階段最多約可保留 4 MiB 請求上限的兩倍。PlainCVE 建議同時監控 MCP 伺服器的記憶體用量。
步驟 1 步驟 2

完整修復步驟與說明

目前版本	升級到	指令
1.8.0 至 1.29.1	1.30.0 以上	`pip install -U "mcp>=1.30.0,<2"`
2.0.0 至 2.1.1	2.2.0 以上	`pip install -U "mcp>=2.2.0"`

升級前要知道的行為改變。 官方 1.30.0 發布說明指出:有狀態工作階段如果 30 分鐘內沒有任何進行中的請求就會被關閉,用戶端下一個請求會收到 404,必須重新 initialize。開著的串流與處理中的請求會讓工作階段保持存活。如果你的用戶端不會自動重新初始化,請先測試。傳入 None 可以恢復舊行為,但 PlainCVE 提醒,這也等於讓閒置工作階段重新變成永不過期。

1.27 至 1.29.1 的使用者。 session_idle_timeout 選項從 1.27 就存在,只是預設關閉;PlainCVE 建議仍以升級為主(升級也會一併修正 DELETE 與被拒工作階段殘留的問題)。

攻擊流程

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

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

圖片可自由用於報導與教學,採 CC BY 4.0,圖上已附出處。

攻擊者
用戶端連上伺服器的 Streamable HTTP 端點
依 CVE 紀錄的評分,不需要權限、也不需要使用者互動。維護者指出,就算有認證,也只能限制誰能開工作階段,不能限制一個持有 token(登入憑證)的人能開多少個。
防禦: 限制誰能連到端點;不需要工作階段狀態時改用 stateless_http=True(1.12.0 以上)。
攻擊者
用一般的短請求不斷開新的工作階段
舊版對同時存在的工作階段數量沒有上限,每個工作階段還會保存解析後的 initialize 參數。
防禦: 升級後最多只能同時有 max_sessions 個(預設 10000),再開會收到 503。
你的系統
結束或被拒絕的工作階段仍留在登記表裡
用戶端送出 DELETE 結束工作階段後,紀錄沒有被移除;第一個請求被拒絕的工作階段也會留著,還附帶一個執行中的任務。
防禦: 修補版在工作階段結束(DELETE、逾時或開啟請求被拒)時立即丟棄。
你的系統
閒置的工作階段永遠不會過期
舊版預設沒有閒置逾時;session_idle_timeout 選項從 1.27 起就有,但預設是關閉的(None)。
防禦: 修補版預設閒置 1800 秒(30 分鐘)就關閉工作階段。
你的系統
記憶體無上限增長,服務可能停擺
只有重啟程序才能回收記憶體。影響僅限可用性。
防禦: 重啟可暫時回收記憶體,但要升級才能根治。

影響範圍

條件	是否受影響
mcp 1.8.0 至 1.29.1,以有狀態模式(預設)提供 Streamable HTTP	受影響
mcp 2.0.0 至 2.1.1,以有狀態模式(預設)提供 Streamable HTTP	受影響
mcp 1.30.0 以上(1.x)或 2.2.0 以上(2.x)	已修補
1.12.0 以上並設定 `stateless_http=True`(不保存工作階段)	不受影響
只使用 stdio 或 SSE 傳輸	不受影響

預設為有狀態模式的元件包括:FastMCP(1.x)、MCPServer 與 Server.streamable_http_app()(2.x),以及 StreamableHTTPSessionManager。維護者的說法是:如果你以有狀態模式提供 Streamable HTTP,而且有不完全信任的用戶端連得到端點,就受影響。依 CVE 紀錄的評分,不需要權限也不需要使用者互動;維護者也提醒,認證(例如要求 token,也就是登入憑證)只能限制「誰」能開工作階段,不能限制一個人能開「多少」個。

原理

MCP(Model Context Protocol)是讓 AI 呼叫外部工具的通訊協定,Streamable HTTP 是它透過 HTTP 傳輸的方式之一。在有狀態模式下,伺服器會為每個用戶端建立一個「工作階段」(session),也就是一筆記住這個用戶端的狀態紀錄。

舊版的問題是這些紀錄只進不出。CVE 紀錄與維護者公告列出幾個原因:

沒有閒置逾時,也沒有工作階段總數上限;
用戶端送出 DELETE 結束工作階段後,紀錄仍留在登記表;
第一個請求被拒絕的工作階段也會留著,還附帶一個執行中的任務;
每個工作階段都保存了解析過的 initialize 參數。

結果是能連到端點的用戶端,用一般的短請求就能讓伺服器記憶體無上限增長,只有重啟才能回收。影響只限於可用性(阻斷服務);CVE 紀錄的評分顯示對機密性與完整性沒有影響,沒有跡象指向執行程式碼或資料外洩。

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

展開程式碼範例(python)

sessions = {}

def open_session(req):
    sessions[new_id()] = Session(req.initialize_params)  # 沒有上限

def close_session(sid):
    sessions[sid].stop()  # 停止了,但沒有從 sessions 移除

修好的思路:

展開程式碼範例(python)

def open_session(req):
    if len(sessions) >= max_sessions:      # 預設 10000
        return 503
    sessions[new_id()] = Session(req.initialize_params)

def close_session(sid):                    # DELETE、逾時或開啟被拒都會走到這裡
    sessions.pop(sid).stop()

# 背景:閒置超過 session_idle_timeout(預設 1800 秒)就關閉,之後該 ID 回 404

修補後保留時間有了上限,但不是完全不保留:每個存活中的工作階段仍會持有 initialize 參數,最多約為 4 MiB 請求上限的兩倍。

時間軸

日期	事件
2026-04-16	專案 issue #2455 開立:`session_idle_timeout` 沒有在高階 API 開放設定;PR #3395 把它列為修補對象之一
2026-07-03	第三方在專案 repo 開立 PR #3059:有狀態模式下,沒有 session ID 的 `GET`/`DELETE` 請求被拒後,工作階段與背景任務不會被清掉、會一直累積(該頁含攻擊程式,本站不連結)。這只是 CVE 與公告列出的成因之一(被拒的開啟請求);它順帶提到只有預設關閉的 `session_idle_timeout` 會清掉這些工作階段,但沒有講到正常 `DELETE` 後紀錄沒有移除、工作階段數量沒有上限,也沒有說這是資安問題。維護者在 PR #3426 說 #3059 只涵蓋了這個問題的一部分
2026-07-07	CVE 編號保留
2026-07-30	第三方在專案 issue #3228 公開回報(該頁含攻擊程式,本站不連結)。原文講到 CVE 與公告列出的多項成因:被拒絕的 Streamable HTTP 請求會留下已登記、沒有結束的工作階段;真正的可用性缺口是沒有工作階段數量上限,加上唯一的閒置清除機制 `session_idle_timeout` 預設關閉、用文件裡的 API 也開不起來;並指出正常流量就可能讓工作階段無限增長。開立當天的原文沒有講到正常 `DELETE` 後紀錄沒有移除;這點是 2026-08-13 同一串討論的留言才補上(見下)。回報者明說不是以資安問題回報
2026-08-13	第三方在專案 issue #3300 公開回報:正常結束(`DELETE`)的工作階段沒有從登記表移除(該頁含攻擊程式,本站不連結)。它只講到這一部分成因,沒有講到數量上限,也沒有說這是資安問題。同一天,issue #3228 也有留言指出成功的 `DELETE` 不會把工作階段移出登記表、登記表會無上限增長
2026-08-26	2.x 修補 PR #3395 開立,公開說明預設設定下沒有送出 `DELETE` 的工作階段會一直留到程序結束,並一併處理閒置逾時、數量上限、`DELETE` 與被拒請求殘留;PR 把它歸為錯誤修正,沒有說這是資安問題。2026-08-28 合併
2026-09-02	1.x 移植版 PR #3426 合併
2026-09-07	維護者在 GitHub 發布 v1.30.0 與 v2.2.0(release 頁顯示 9 月 7 日;年份依 PR #3426 於 2026-09-02 合併推得)
2026-09-30	維護者 GitHub 安全公告 GHSA-84m7-p3x7-pcfv 公開,完整描述這個漏洞;本頁以這天為首次公開日(官方公告與 CVE 紀錄中較早者)。更早的專案 issue #3228(2026-07-30)已公開描述多項成因,但開立時沒有涵蓋全部成因,也不是以資安問題回報,依 PlainCVE 的保守做法放在時間軸
2026-10-14	CVE 紀錄公開
2026-10-15	GitHub Advisory Database 收錄已審核條目 GHSA-84m7-p3x7-pcfv(published_at 2026-10-15T20:13:13Z,severity medium,同時列 CVSS 3.1 7.5 與 CVSS 4.0 6.9,CWE-400/770/772);截至這天不在 CISA KEV
2026-10-17	NVD 狀態為 Awaiting Analysis(尚未分析)

PlainCVE 的判斷:修補版比公告早約三週、比 CVE 早約五週發布。沒有任何來源把這段時間差與實際攻擊連在一起。

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

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

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

來源

安全公告GHSA-84m7-p3x7-pcfv — Unbounded session accumulation in Streamable HTTP transport · modelcontextprotocol (GitHub), 2026-09-30 · 查閱 2026-10-15
CVE / NVD / OSVCVE-2026-59951 Record · CVE Program, 2026-10-14 · 查閱 2026-10-15
CVE / NVD / OSVNVD API - CVE-2026-59951 · NIST · 查閱 2026-10-15
修補 commit / 版本Expire idle Streamable HTTP sessions by default and cap concurrent sessions (PR #3395) · modelcontextprotocol (GitHub), 2026-08-26 · 查閱 2026-10-15
修補 commit / 版本Commit d2290ca3434731b68ea3e2270bc06a6e6575931b (2.x fix) · modelcontextprotocol (GitHub) · 查閱 2026-10-15
修補 commit / 版本v1.x backport of #3395 (PR #3426) · modelcontextprotocol (GitHub) · 查閱 2026-10-15
修補 commit / 版本mcp v2.2.0 release · modelcontextprotocol (GitHub), 2026-09-07 · 查閱 2026-10-15
修補 commit / 版本mcp v1.30.0 release · modelcontextprotocol (GitHub), 2026-09-07 · 查閱 2026-10-15
其他mcp-proxy issue #252: sessions accumulate without bound on mcp 1.26.0 · sparfenyuk/mcp-proxy (GitHub) · 查閱 2026-10-15
其他Issue #2455: session_idle_timeout not exposed · modelcontextprotocol (GitHub), 2026-04-16 · 查閱 2026-10-17
其他GitHub Advisory Database query for CVE-2026-59951 · GitHub, 2026-10-15 · 查閱 2026-10-17

媒體簡報

一句話

MCP Python SDK(PyPI 套件名稱 mcp)是 MCP 的 Python 實作,用來開發 MCP 伺服器;MCP 是讓 AI 呼叫外部工具與資料的通訊協定。它的 Streamable HTTP 傳輸在預設的有狀態模式下不會清除舊的工作階段,能連上端點的用戶端可讓伺服器記憶體無上限增長,直到重啟。修補版 1.30.0 與 2.2.0 已發布;截至 2026-10-15 這個漏洞不在 CISA 已知遭利用漏洞清單,也沒有來源回報實際攻擊。

關鍵數字

CNA 評分: CVSS 4.0 6.9(中) cveawg.mitre.org
維護者評分: CVSS 3.1 7.5(高) github.com
修補版本: 1.30.0(1.x)、2.2.0(2.x) github.com
安全公告公開: 2026-09-30(GHSA-84m7-p3x7-pcfv) github.com
CVE 公開: 2026-10-14 cveawg.mitre.org

已確認

受影響版本(1.8.0–1.29.1、2.0.0–2.1.1)的有狀態模式 Streamable HTTP 伺服器會無限保留工作階段,記憶體只有重啟才能回收。
官方修補版為 1.30.0 與 2.2.0;只用 stdio/SSE 或設定 stateless_http=True(1.12.0 以上)的伺服器不受影響。
截至 2026-10-15 不在 CISA KEV 清單中。
第三方營運者在正常使用 1.26.0 時觀察到工作階段無限累積,升到 1.30.0 後消失;這不是攻擊證據。

尚未確認 / 說法不一

沒有來源回報實際遭利用,也沒有來源說它在修補前就被利用(零時差)。
嚴重度說法不一:CNA 給 CVSS 4.0 6.9(中),維護者公告給 CVSS 3.1 7.5(高);NVD 尚未分析。
弱點分類不一:CVE 紀錄列 CWE-400,維護者公告列 CWE-770,兩者都列 CWE-772。

可引用的一句話

這不是有人闖進門,而是一間只開放入住、從不退房的旅館,房間總有用完的一天。

圖片

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

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

MCP Python SDK 工作階段無限累積:能連上有狀態 Streamable HTTP 端點的用戶端可讓伺服器記憶體一直增長

MCP Python SDK(PyPI 套件名稱 mcp)是 MCP 的 Python 實作,用來開發 MCP 伺服器;MCP 是讓 AI 呼叫外部工具與資料的通訊協定。它的 Streamable HTTP 傳輸在預設的有狀態模式下不會清除舊的工作階段,能連上端點的用戶端可讓伺服器記憶體無上限增長,直到重啟。修補版 1.30.0 與 2.2.0 已發布;截至 2026-10-15 這個漏洞不在 CISA 已知遭利用漏洞清單,也沒有來源回報實際攻擊。

關鍵數字:
- CNA 評分:CVSS 4.0 6.9(中)(https://cveawg.mitre.org/api/cve/CVE-2026-59951)
- 維護者評分:CVSS 3.1 7.5(高)(https://github.com/modelcontextprotocol/python-sdk/security/advisories/GHSA-84m7-p3x7-pcfv)
- 修補版本:1.30.0(1.x)、2.2.0(2.x)(https://github.com/modelcontextprotocol/python-sdk/security/advisories/GHSA-84m7-p3x7-pcfv)
- 安全公告公開:2026-09-30(GHSA-84m7-p3x7-pcfv)(https://github.com/modelcontextprotocol/python-sdk/security/advisories/GHSA-84m7-p3x7-pcfv)
- CVE 公開:2026-10-14(https://cveawg.mitre.org/api/cve/CVE-2026-59951)

已確認:
- 受影響版本(1.8.0–1.29.1、2.0.0–2.1.1)的有狀態模式 Streamable HTTP 伺服器會無限保留工作階段,記憶體只有重啟才能回收。
- 官方修補版為 1.30.0 與 2.2.0;只用 stdio/SSE 或設定 stateless_http=True(1.12.0 以上)的伺服器不受影響。
- 截至 2026-10-15 不在 CISA KEV 清單中。
- 第三方營運者在正常使用 1.26.0 時觀察到工作階段無限累積,升到 1.30.0 後消失;這不是攻擊證據。

尚未確認 / 說法不一:
- 沒有來源回報實際遭利用,也沒有來源說它在修補前就被利用(零時差)。
- 嚴重度說法不一:CNA 給 CVSS 4.0 6.9(中),維護者公告給 CVSS 3.1 7.5(高);NVD 尚未分析。
- 弱點分類不一:CVE 紀錄列 CWE-400,維護者公告列 CWE-770,兩者都列 CWE-772。

「這不是有人闖進門,而是一間只開放入住、從不退房的旅館,房間總有用完的一天。」— PlainCVE
https://plaincve.date/vulns/cve-2026-59951-mcp-python-sdk-session-exhaustion

如何引用本頁

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

PlainCVE 團隊(2026)。《MCP Python SDK 工作階段無限累積:能連上有狀態 Streamable HTTP 端點的用戶端可讓伺服器記憶體一直增長》。PlainCVE。https://plaincve.date/vulns/cve-2026-59951-mcp-python-sdk-session-exhaustion(查閱日期:YYYY-MM-DD)

BibTeX

@misc{cve202659951mcppythonsdksessionexhaustion2026,
  title  = {MCP Python SDK 工作階段無限累積:能連上有狀態 Streamable HTTP 端點的用戶端可讓伺服器記憶體一直增長},
  author = {PlainCVE 團隊},
  year   = {2026},
  howpublished = {PlainCVE},
  url    = {https://plaincve.date/vulns/cve-2026-59951-mcp-python-sdk-session-exhaustion},
  note   = {更新於 2026-10-19}
}