plaincve:~$

// threat brief

CVE-2026-109527

MCP Python SDK has no request body size limit: one huge request can exhaust server memory

CVSS
7.5 HIGH
CISA KEV
Not listed
Weakness
CWE-770
Topics
AI security · Web apps

PlainCVE Team · Published 2026-10-19 · AI-assisted · Press brief ↓

AI review 2026-10-19 (not human-reviewed)Command tests: none yetReproduced: not yetVerification record ↓

The official MCP Python SDK's HTTP server endpoints read request bodies with no size limit, so a client can repeatedly exhaust memory and take the server down.

Who is affectedMCP servers using the pip package mcp before 1.29.1 or a 2.0.x release, serving over HTTP transports (Streamable HTTP, SSE) or the built-in OAuth authorization routes, reachable over HTTP by clients you do not fully trust, with no reverse proxy or gateway in front that already caps request size. Servers that only use stdio, and MCP clients, are not affected.
What happensDenial of service: one oversized request grows the server process's memory by roughly two to three times the body size, and this can be repeated to exhaust memory or terminate the server. The CVSS rating has no confidentiality or integrity impact.
What to do nowUpgrade to mcp 1.29.1 (1.x) or 2.1.0 (2.x) or later; there is no fixed 2.0.x release. If you cannot upgrade yet, cap request body size in a reverse proxy or ASGI middleware.
Affected versionsAll versions earlier than 1.29.1 (1.29.1 itself is not affected); on 2.x, the vendor advisory lists 2.0.0 through 2.0.1, while the CVE record also includes pre-releases from 2.0.0a1 (sources disagree)
Fixed versions1.29.1 or later (1.x), 2.1.0 or later (2.x); no fixed 2.0.x release
CVSS vector
Show full vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Timeline
  • First public 2026-09-30

Blue team playbook

Check, fix / mitigate, respond, harden. Matching the affected versions does not mean you were compromised, and a check that finds nothing does not prove you are safe; each item says what it can and cannot show. Tagged steps point to where the attack flow below can be stopped.

DETECTCheckAm I affected? Any signs of compromise?
  1. 01Check your mcp version and exposure

    Run this read-only command inside the Python environment the MCP server actually uses (for example its virtualenv); run elsewhere, it may report a different install. You are affected only if all hold: mcp before 1.29.1 or 2.0.x, the server uses an HTTP transport or the built-in OAuth routes, clients you don't fully trust can reach it, and no reverse proxy in front already caps request size. Servers that only use stdio, and MCP clients, are not affected.

    Read-only check
    python -m pip show mcp | grep -i '^version'
  2. 02Find code that uses StreamableHTTPServerTransport directly

    Per the vendor: code that drives StreamableHTTPServerTransport directly, without the session manager, does not get the limit even after upgrading and must bound request bodies itself. The command is a read-only search; run it from the root of your own project's source tree.

    Read-only check
    grep -rn "StreamableHTTPServerTransport" --include='*.py' .
    Step 2
MITIGATEFix / mitigatePatch; block it if you cannot patch yet
  1. 01On 1.x: upgrade to 1.29.1 or later (staying on 1.x)

    This command changes your environment (it installs a new package version); run it inside the Python environment the MCP server uses (for example its virtualenv). After the fix, the SDK's standard server applications and session managers share one request body limit (4 MiB by default). 1.29.0 only covered Streamable HTTP; the SSE and OAuth endpoints stayed unlimited, so it is not a complete fix.

    Changes your environment
    python -m pip install -U "mcp>=1.29.1,<2"
    Step 2Step 3
  2. 02On 2.x: upgrade to 2.1.0 or later

    This command changes your environment (it installs a new package version); run it inside the Python environment the MCP server uses (for example its virtualenv). There is no fixed 2.0.x release; 2.0.0 only covered Streamable HTTP, so it is not a complete fix. 1.x users should not use this command, or they will jump a major version to 2.x.

    Changes your environment
    python -m pip install -U "mcp>=2.1.0"
    Step 2Step 3
  3. 03Can't upgrade yet: cap request size in front

    Vendor advice: cap request body size in a reverse proxy or ASGI middleware in front of the server.

    Step 1Step 2
RESPONDRespondIf you find signs of compromise
  1. 01After upgrading, watch for rejected oversized requests (HTTP 413)

    PlainCVE's suggestion and wording (read-only). Run it on your own reverse-proxy host; it assumes nginx with logs under /var/log/nginx and searches every access log in that folder and its subfolders, including rotated and .gz-compressed files. Adjust the path if yours differs. Note: this only finds requests rejected with 413 after upgrading. Before the fix, oversized requests did not get 413, and the default access-log format may not record request body size, so it cannot find the requests from a past outage. If the service went down from memory exhaustion, also compare requests to the MCP HTTP or OAuth endpoints during that window with the server's memory records. The impact of this flaw is availability only.

    Read-only check
    find /var/log/nginx -type f -name '*access*' -exec zgrep -H '" 413 ' {} +
    Step 3Step 4
HARDENHardenPrevent the next one
  1. 01Don't expose MCP servers directly to untrusted clients

    Put a reverse proxy or gateway that caps request size in front, so similar problems later still hit a second layer.

    Step 1
  2. 02Raise the limit only when needed

    Per the vendor: if your clients really send single messages over 4 MiB, raise the limit with max_request_body_size. PlainCVE's suggestion: raise it rather than removing it.

    Step 2
Full remediation steps and notes
Your current versionUpgrade to
1.x (before 1.29.1, including 1.29.0)1.29.1 or later, e.g. pip install -U "mcp>=1.29.1,<2"
2.0.x (including pre-releases)2.1.0 or later, e.g. pip install -U "mcp>=2.1.0"; there is no fixed 2.0.x release
  • 1.29.0 and 2.0.0 are not enough. They protect only Streamable HTTP; the SSE and OAuth endpoints stay unlimited.
  • When you still need to act after upgrading. Code that uses StreamableHTTPServerTransport directly, without the session manager, does not get the limit and must bound request size itself.
  • Legitimately large messages. If your clients really send single messages over 4 MiB, the vendor says to raise the limit with the max_request_body_size parameter; the 2.1.0 release notes say SseServerTransport and MCPServer.sse_app() also accept it. In the same release, the SSE message endpoint answers 405 to non-POST requests.
  • If you can’t upgrade yet. The vendor advises capping request size in a reverse proxy or in ASGI middleware (code wrapped around a Python web app that handles requests first) in front of the server.

Attack flow

Read left to right: this is the order the attack happens in. A blue shield means the step can be stopped; the earlier, the better. Click an icon for details.

Read top to bottom: this is the order the attack happens in. A blue shield means the step can be stopped; the earlier, the better. Tap an icon for details.

MCP Python SDK has no request body size limit: one huge request can exhaust server memory: 1. Sends a request with a very large body to an MCP server's HTTP endpoint → 2. The server reads the whole request body into memory before checking its size → 3. Memory use balloons → 4. The server runs out of memory and goes offline, repeatedlyCVE-2026-109527 · MCP Python SDK has no request body size limit: one huge request canexhaust server memoryAttackerYour systemSends a request with a very large body to an MCP server's HTTP endpoint — The affected parts are the Streamable HTTP session manager, the SSE message endpoint and the OAuth authorization routes. Against the OAuth endpoints, or a server that does not require authentication (the default), no credentials are needed. 1Sends a requestwith a very largebody to an MCPserver's HTT…The server reads the whole request body into memory before checking its size — Per the vendor advisory, older versions read the whole body into memory before checking its size. From 1.29.0 and 2.0.0, Streamable HTTP had a 4 MiB limit; the SSE message endpoint and the OAuth endpoints had no limit at all until 1.29.1 and 2.1.0. 2The server readsthe whole requestbody into memorybefore checkin…Memory use balloons — The vendor advisory says one large request grows process memory by about two to three times the body size. 3Memory use balloonsThe server runs out of memory and goes offline, repeatedly — The impact is availability only; no source mentions code execution or data exposure. 4The server runsout of memory andgoes offline,repeatedlyAttack pathCan be stopped herePlainCVE · plaincve.date/en/vulns/cve-2026-109527-mcp-python-sdk-body-size-dos · CC BY 4.0
MCP Python SDK has no request body size limit: one huge request can exhaust server memory: 1. Sends a request with a very large body to an MCP server's HTTP endpoint → 2. The server reads the whole request body into memory before checking its size → 3. Memory use balloons → 4. The server runs out of memory and goes offline, repeatedlyCVE-2026-109527 · MCP Python SDK has norequest body size limit: one hugerequest can exhaust server memorySends a request with a very large body to an MCP server's HTTP endpoint — The affected parts are the Streamable HTTP session manager, the SSE message endpoint and the OAuth authorization routes. Against the OAuth endpoints, or a server that does not require authentication (the default), no credentials are needed. 1AttackerSends a request with a verylarge body to an MCP server'sHTTP endpointThe server reads the whole request body into memory before checking its size — Per the vendor advisory, older versions read the whole body into memory before checking its size. From 1.29.0 and 2.0.0, Streamable HTTP had a 4 MiB limit; the SSE message endpoint and the OAuth endpoints had no limit at all until 1.29.1 and 2.1.0. 2Your systemThe server reads the wholerequest body into memory beforechecking its sizeMemory use balloons — The vendor advisory says one large request grows process memory by about two to three times the body size. 3Your systemMemory use balloonsThe server runs out of memory and goes offline, repeatedly — The impact is availability only; no source mentions code execution or data exposure. 4Your systemThe server runs out of memoryand goes offline, repeatedlyAttack pathCan be stopped herePlainCVE · CC BY 4.0plaincve.date/en/vulns/cve-2026-109527-mcp-python-sdk-body-size-dos
Free to use in reporting and teaching under CC BY 4.0. Attribution is already on the image.
  1. Attacker

    Sends a request with a very large body to an MCP server's HTTP endpoint

    The affected parts are the Streamable HTTP session manager, the SSE message endpoint and the OAuth authorization routes. Against the OAuth endpoints, or a server that does not require authentication (the default), no credentials are needed.

    Defense: Don't let clients you don't fully trust reach the server directly; put a reverse proxy or gateway that caps request size in front.

  2. Your system

    The server reads the whole request body into memory before checking its size

    Per the vendor advisory, older versions read the whole body into memory before checking its size. From 1.29.0 and 2.0.0, Streamable HTTP had a 4 MiB limit; the SSE message endpoint and the OAuth endpoints had no limit at all until 1.29.1 and 2.1.0.

    Defense: Upgrade to 1.29.1 or 2.1.0 or later: requests over the limit (4 MiB by default) get HTTP 413 before any parsing.

  3. Your system

    Memory use balloons

    The vendor advisory says one large request grows process memory by about two to three times the body size.

    Defense: If you can't upgrade yet, cap request body size with ASGI middleware.

  4. Your system

    The server runs out of memory and goes offline, repeatedly

    The impact is availability only; no source mentions code execution or data exposure.

Who is affected

The affected software is the official Python SDK for MCP (Model Context Protocol, a standard that lets AI call external tools), the pip package mcp. Only servers are affected.

ConditionAffected?
mcp earlier than 1.29.1 (1.x, not including 1.29.1)Affected (1.29.0 fixed only Streamable HTTP, so it’s incomplete)
mcp 2.0.0, 2.0.1Affected (2.0.0 fixed only Streamable HTTP, so it’s incomplete)
mcp 2.0.0 alpha, beta and rc pre-releases from 2.0.0a1Sources disagree: the CVE record and OSV list them as affected; the vendor advisory’s range starts at 2.0.0 and doesn’t mention pre-releases
mcp 1.29.1 or later, 2.1.0 or laterFixed
Servers that only use the stdio transportNot affected
MCP clients built with the SDKNot affected
Behind a reverse proxy (a service in front of the server that receives requests first) or gateway that already caps request sizeNot affected

The vendor’s framing: you need to act if clients you do not fully trust can reach your server over HTTP. Against the OAuth endpoints, or against a server that does not require authentication (the default), an attacker needs no credentials. The advisory does not say whether a server that requires authentication can be attacked without credentials on its Streamable HTTP or SSE endpoints.

How it works

The SDK has three built-in HTTP entry points: the Streamable HTTP session manager, the SSE message endpoint, and the OAuth authorization-server routes (/token, /register, /revoke, /authorize). In older versions, these read the entire request body into memory before checking its size (the vendor advisory’s wording). From 1.29.0 and 2.0.0, Streamable HTTP had a 4 MiB limit; the SSE message endpoint and the OAuth routes had no limit at all until 1.29.1 and 2.1.0.

According to the vendor advisory, one large request grows the server process’s memory by about two to three times the body size. A client that can reach the server can therefore exhaust its memory and take it offline, again and again. This kind of mistake maps to CWE-770 (allocation of resources without limits or throttling). The CVSS rating covers availability only, with no confidentiality or integrity impact; no source mentions code execution or data exposure.

The flawed approach (conceptual illustration, not the original source code):

Show code example(python)
body = await read_entire_body(request)   # reads everything into memory first, size checked only afterwards
message = parse(body)

The fixed approach:

Show code example(python)
body = await read_body_with_limit(request, max_size=4 * 1024 * 1024)
# as soon as the declared or streamed size exceeds the limit, answer 413 before parsing
message = parse(body)

The fix came in two stages: 1.29.0 and 2.0.0 first added a 4 MiB limit to Streamable HTTP; 1.29.1 and 2.1.0 then extended the same limit to the SSE message endpoint and the OAuth routes.

Timeline

DateEvent
2026-07-14The project opens public PR #3095 (that page contains attack code, so we do not link it; its fix commit is 03aaebd), adding a request body limit to Streamable HTTP (max_request_body_size, 413 when exceeded). On 2026-07-15 an automated review comment posted by claude[bot] (a bot comment, not an official security disclosure or advisory) notes the SSE POST endpoint still buffers the whole body unbounded, “the same DoS vector this PR closes”. That comment covers only the SSE endpoint; it does not mention the OAuth authorization routes or the roughly two-to-three-times memory amplification, so we still date first public disclosure to the 2026-09-30 advisory
2026-07-16PR #3095 merged
2026-08-19The project opens public PR #3336 (its fix commit is 57394b0), extending the same limit to the SSE message endpoint and OAuth routes (merged 08-20)
2026-08-24Per PyPI upload records (1.29.1, 2.1.0), v1.29.1 and v2.1.0 released, fixing the SDK’s standard server applications and session managers; about five weeks before the advisory
2026-09-30Vendor GitHub security advisory GHSA-fmmv-w9g8-j3gc published
2026-10-12CVE ID reserved
2026-10-14CVE record published
2026-10-15Not listed in CISA’s Known Exploited Vulnerabilities catalog, per PlainCVE’s KEV snapshot

Further reading

  • Scoring: The CNA (GitHub) gives CVSS 3.1 7.5, vector AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, matching the vendor advisory. As checked on 2026-10-19, NVD’s status is “Awaiting Analysis” (last modified 2026-10-16) and NVD has not scored it itself; the 7.5 shown on NVD is the Secondary score supplied by the CNA (security-advisories@github.com), not an NVD score.
  • Disagreement on the 2.x range: The vendor advisory says 2.0.0 up to but not including 2.1.0; the CVE record starts at 2.0.0a1, and OSV also lists v2.0.0b1, v2.0.0b2 and v2.0.0rc1. To be safe, treat all 2.0.x pre-releases as affected.
  • When the bug started: No source names the commit that introduced it. OSV’s range starts at “0” (no known starting point); our analysis is that these HTTP endpoints may have lacked a size limit since early versions.
  • Exploitation: Not in CISA KEV as of 2026-10-15. No source says whether it has been exploited in the wild or whether it was a zero-day. An automated review comment by claude[bot] on the project’s public PR #3095 gives steps to reproduce memory exhaustion on the SSE message endpoint (that page contains attack code, so we do not link it); beyond that, no source mentions a public proof-of-concept.
  • Database status: In this snapshot, querying the GitHub Advisory Database API by CVE ID returned an empty result, although the project’s own advisory exists.
  • Credits: The vendor advisory credits GitHub users razashariff and shmulc8 as reporters.
  • Related weakness type: CWE-770. Fix commits: on 1.x, 5f0b6af (#3101) and 4dc224f; on 2.x, 03aaebd (#3095) and 57394b0 (#3336).

Verification Checked item by item against sources by AI under our review rules, all passed; not human-reviewed and not yet reproduced in our lab

AI review2026-10-19 · review rules

Verification records describe the environment and the result only, never reproduction steps or code that could attack other people’s systems. See our policy.

Sources

  1. AdvisoryGHSA-fmmv-w9g8-j3gc — MCP Python SDK request body size limit · Model Context Protocol (GitHub), 2026-09-30 · accessed 2026-10-15
  2. CVE / NVD / OSVCVE-2026-109527 Record (CVE Services API) · CVE Program, 2026-10-14 · accessed 2026-10-15
  3. CVE / NVD / OSVNVD API - CVE-2026-109527 · NIST · accessed 2026-10-15
  4. Patch / release[v1.x] Add Streamable HTTP request body limits (#3101) · Model Context Protocol (GitHub) · accessed 2026-10-15
  5. Patch / release[v1.x] Apply the request body limit to the SSE and OAuth endpoints · Model Context Protocol (GitHub) · accessed 2026-10-15
  6. Patch / releaseAdd Streamable HTTP request body limits (#3095) · Model Context Protocol (GitHub) · accessed 2026-10-15
  7. Patch / releaseApply the request body limit to the SSE and OAuth endpoints (#3336) · Model Context Protocol (GitHub) · accessed 2026-10-15
  8. Patch / releasemcp v1.29.1 release · Model Context Protocol (GitHub) · accessed 2026-10-15
  9. Patch / releasemcp v2.1.0 release · Model Context Protocol (GitHub) · accessed 2026-10-15
  10. OtherPyPI JSON API - mcp 1.29.1 · PyPI · accessed 2026-10-15
  11. OtherPyPI JSON API - mcp 2.1.0 · PyPI · accessed 2026-10-15
  12. OtherOSV - CVE-2026-109527 · OSV · accessed 2026-10-15
  13. OtherGitHub Advisory Database API query for CVE-2026-109527 · GitHub · accessed 2026-10-15

Press brief

In one sentence

MCP (Model Context Protocol) lets AI call external tools, and its official Python SDK read request bodies on its HTTP server endpoints with no size limit. A client that can reach the server could send oversized requests to exhaust memory and take the service down, repeatedly. The project fixed the SDK's built-in servers in 1.29.1 and 2.1.0 (released August 24, 2026) and published its advisory on September 30, 2026. As of October 15, 2026, it is not in CISA's Known Exploited Vulnerabilities catalog.

Key facts

Severity
CVSS 3.1 7.5 (from the CNA; NVD status Awaiting Analysis as of 2026-10-19, not yet scored by NVD) cveawg.mitre.org
Fixed versions
1.29.1 (1.x), 2.1.0 (2.x) github.com
First public
2026-09-30 (publication date of GHSA-fmmv-w9g8-j3gc, earlier than the CVE record's 2026-10-14) github.com
Advisory published
2026-09-30 (GHSA-fmmv-w9g8-j3gc) github.com
CVE published
2026-10-14 cveawg.mitre.org
Reported by
GitHub users razashariff and shmulc8 github.com

Confirmed

  • The Streamable HTTP, SSE message and OAuth authorization endpoints read request bodies with no size limit.
  • The impact is denial of service: memory can be exhausted repeatedly to take the server offline; the CVSS rating has no confidentiality or integrity impact.
  • 1.29.1 and 2.1.0 fix the SDK's standard server applications and session managers; code that uses StreamableHTTPServerTransport directly must still bound request size itself after upgrading; there is no fixed 2.0.x release.

Unconfirmed / disputed

  • Whether the 2.0.0 alpha, beta and rc pre-releases are affected: the CVE record and OSV say yes; the vendor advisory does not mention them.
  • Whether it has been exploited in the wild is not stated by any source. An automated review comment by claude[bot] on the project's public PR
  • Whether a server that requires authentication can be attacked without credentials on its Streamable HTTP or SSE endpoints is not stated in the advisory.

Quotable line

A server that accepts every parcel without asking how big it is will eventually run out of room.

Images

Download the share image (PNG) · Attack flow diagram (downloadable)

Please credit "PlainCVE" and link to this page. Full citation format is under "How to cite" below. Found a factual error? Report it.

How to cite this page

This article is CC BY 4.0. Please keep the attribution and link when republishing.

PlainCVE Team (2026). "MCP Python SDK has no request body size limit: one huge request can exhaust server memory". PlainCVE. https://plaincve.date/en/vulns/cve-2026-109527-mcp-python-sdk-body-size-dos (accessed YYYY-MM-DD)
BibTeX
@misc{cve2026109527mcppythonsdkbodysizedos2026,
  title  = {MCP Python SDK has no request body size limit: one huge request can exhaust server memory},
  author = {PlainCVE Team},
  year   = {2026},
  howpublished = {PlainCVE},
  url    = {https://plaincve.date/en/vulns/cve-2026-109527-mcp-python-sdk-body-size-dos},
  note   = {Updated 2026-10-19}
}