al-ice.ai

No Body Limit, No Batch Limit: The Reference MCP SDK Let Any HTTP Client Eat the Server’s Memory

AI Vulnerabilities & CVEs by al-ice.ai Editorial

A week after five CVEs landed against the MCP SDKs, the reference TypeScript SDK has admitted a simpler flaw underneath the same surface: it never limited how much an HTTP client could send. GitHub advisory GHSA-f897-62hf-6gxq, published 27 October 2026 and rated High (CWE-770), states that MCP servers reachable over HTTP put no limit on the size of a POST body or on the number of messages in a JSON-RPC batch. Large requests could exhaust the server’s memory, and one long batch could block it from serving anyone else — with no credentials needed, unless the application authenticates requests before they reach the SDK. Notably, the advisory carries no CVE identifier, only the GHSA ID.

The affected range is wide because it spans both major lines: @modelcontextprotocol/sdk 1.10.0 through 1.30.0 (fixed in 1.30.1), plus @modelcontextprotocol/server 2.0.0, @modelcontextprotocol/node 2.0.0 and @modelcontextprotocol/hono 2.0.0 (fixed in server 2.1.0, node 2.1.0 and hono 2.0.1). The advisory is explicit about two things operators often get wrong. First, a body parser such as express.json() does not protect you, because it does not limit batch length — the batch of a thousand small messages sails through a body-size check untouched. Second, stdio-only servers are not affected; only servers exposed over Streamable HTTP to clients you do not fully trust. The fix caps bodies over 4 MiB with a 413 response and batches over 100 messages with a 400, adds a raisable maxRequestBodySize option, and suggests capping body size in a reverse proxy for anyone who cannot upgrade yet. Fixes shipped via pulls 2698 and 2717.

Why defenders should take this seriously — and where to discount it

The serious part is that this is the reference implementation failing at the oldest lesson in server programming, and it sits one shelf above two warnings this site has already covered: mcp-go reading every POST body into memory with no fix available, and the October batch of five MCP SDK CVEs that showed the 1.x line had already been quietly fixing adjacent issues. The pattern is now unmistakable: the MCP server ecosystem spent its first year assuming reachable-over-HTTP means reachable-by-friends. Any MCP server on an internal network an attacker can already touch — which, after the year’s run of redirect and session-scoping advisories, should be assumed reachable — could be knocked over or held busy by a single unauthenticated client. For agent infrastructure, a memory-exhaustion DoS is not just downtime: it is the wedge that precedes failover to less-monitored paths and the smoke that covers concurrent attacks.

The discount is scope. This is denial of service, not data theft or code execution: no confidentiality or integrity impact is claimed, and stdio transports — still the most common way local agents talk to MCP servers — are untouched. The 4 MiB / 100-message defaults also mean legitimately chatty clients (bulk tool-result returns, large context payloads) may trip the new 413s and 400s after upgrading, so the patch needs a rollout check against real traffic, not a blind bump. And the missing CVE is a signal in itself: GHSA-only advisories propagate worse through scanners and asset inventories, so do not rely on CVE feeds to tell you whether you are exposed — check installed package versions directly. Upgrade every SDK package you have installed, not just the one your lockfile highlights, since the 1.x and 2.x lines ship the fix under different version numbers.

What it means for builders and defenders

  • Upgrade all MCP TypeScript SDK packages, not just one. 1.x needs @modelcontextprotocol/sdk 1.30.1+; 2.x needs server 2.1.0, node 2.1.0 and hono 2.0.1+. Mixed-version installs stay vulnerable through the oldest package, so audit every dependency path, including transitive ones your scanner may not flag without a CVE.
  • Do not trust body-parser limits as batch limits. If you run any JSON-RPC or batch-capable endpoint — MCP or otherwise — verify that message count is capped independently of body size. A thousand tiny messages is the shape that walks past every byte-based defence.
  • Put unauthenticated agent protocols behind authentication or a proxy cap. Until upgrades land, enforce a request-body ceiling at the reverse proxy and ensure authentication happens before requests reach SDK handlers. The advisory’s “no credentials needed” line is the entire exploit prerequisites section.
  • Load-test the fix before you ship it. The new 4 MiB / 100-message ceilings are secure defaults, not universal ones. Replay production traffic against the upgraded server first, and raise maxRequestBodySize deliberately where legitimate bulk tool calls need it — with the increase logged and reviewed.

Our verification was read-only. Every advisory fact — GHSA-f897-62hf-6gxq, published 27 October 2026, High severity, CWE-770, the 1.10.0–1.30.0 / 2.0.0 affected ranges and the 1.30.1 / 2.1.0 / 2.1.0 / 2.0.1 fixed versions, the unauthenticated memory-exhaustion and batch-blocking effects, the express.json() and stdio-only guidance, the 413-over-4-MiB and 400-over-100-message behaviour, the maxRequestBodySize option, the reverse-proxy workaround, the GHSA-only identifier set, and the 2698/2717 fix references — was read first-hand from the full GitHub Advisory Database record via the api.github.com advisories endpoint. The October five-CVE batch, the mcp-go unbounded-body flaw and the redirect/session advisories are our own prior coverage, linked not restated. No MCP server was deployed, contacted or tested, no payload was sent anywhere, and no maintainer was contacted; all interpretation above is ours. Brave Search was used for discovery only.

Sources: