GitHub reviewed advisory GHSA-f897-62hf-6gxq for the MCP TypeScript SDK on October 27, 2026: HTTP MCP servers built on the SDK put no limit on the size of a POST body or on the number of messages in a JSON-RPC batch. One unauthenticated client could exhaust the server's memory, and one long batch could block the server from serving anyone else. It is rated high (CVSS 7.5) with no CVE assigned. If you run an MCP server over Streamable HTTP, update @modelcontextprotocol/sdk to 1.30.1 or the 2.x packages to the versions below.
| Question | Short answer |
|---|---|
| Am I affected? | Yes, if untrusted clients can reach your MCP server over HTTP using sdk 1.10.0 – 1.30.0, or 2.0.0 of the server, node or hono packages |
| Is there a fix? | Yes: sdk 1.30.1; server 2.1.0; node 2.1.0; hono 2.0.1 |
| Do I need credentials to attack it? | No, unless your app authenticates requests before they reach the SDK |
| Are stdio servers affected? | No |
| Does data leave my machine? | No. This is an availability flaw, not a data leak |
| Is it exploited in the wild? | The advisory does not say so |
This is the third SDK advisory batch this month. We covered the OAuth issuer flaw on October 13 and four advisories fixed in 1.32.0 on October 20, one of which was a different memory exhaustion bug. This one is separate: it concerns the transport and handler layer (body size and batch length), not the validation of tool input.
What does the GHSA-f897-62hf-6gxq flaw do?
According to the advisory, in affected versions an MCP server reachable over HTTP imposed two missing limits:
- No cap on request body size. The transport read the whole POST body before handling it, however large.
- No cap on JSON-RPC batch length. JSON-RPC lets a client send an array of messages in one request. The SDK processed whatever length arrived.
The consequences differ. A very large body can exhaust the Node.js process's memory. A long batch ties up the server on one request so it cannot answer other clients. The CVSS vector is network reachable, low complexity, no privileges, no user interaction, with high availability impact. The weakness class is CWE-770, allocation of resources without limits.
Nothing in the advisory describes code execution or data theft. The damage is an outage of your MCP server, and with it every agent that depends on it.
Who is affected, and how to check
The advisory lists these ranges:
| Package | Affected | Fixed |
|---|---|---|
@modelcontextprotocol/sdk | 1.10.0 – 1.30.0 | 1.30.1 |
@modelcontextprotocol/server | 2.0.0 | 2.1.0 |
@modelcontextprotocol/node | 2.0.0 | 2.1.0 |
@modelcontextprotocol/hono | 2.0.0 | 2.0.1 |
If you use the 2.x packages, upgrade every one you have installed. You are affected when untrusted clients can reach the server over Streamable HTTP. A server that only speaks stdio, which is how most local MCP servers are launched by a coding agent, is not.
Beam has pages for this advisory and the tool: see and the MCP TypeScript SDK tool page.
To check your project:
npm ls @modelcontextprotocol/sdk
npm ls @modelcontextprotocol/server @modelcontextprotocol/node @modelcontextprotocol/hono
Run both in each repository that ships an MCP server, and in any container image that bundles one. A lockfile can pin an old version even when package.json says ^1.x.
What should I do?
Upgrade. Move to the fixed version for each package you have. After the update the SDK enforces two limits: bodies over 4 MiB receive HTTP 413, and batches over 100 messages receive HTTP 400.
Check whether your clients need more. If a legitimate client sends bodies larger than 4 MiB, requests will start failing with 413 after the update. The advisory says to raise the new maxRequestBodySize option rather than removing limits. Set it to the smallest value your real traffic needs.
If you cannot upgrade yet, cap the body at the edge. The advisory's workaround is a request size cap in a reverse proxy. It also warns that a body parser such as express.json() does not limit batch length, so it only partly helps: a small body can still carry a long batch.
Authenticate before the SDK. The advisory says no credentials are needed unless your application authenticates requests before they reach the SDK. If your MCP endpoint is public, putting authentication in front of it shrinks who can send the request, though it does not fix the flaw.
Look in your logs. There is no signature specific to this bug, so look for the symptoms: unusually large POST bodies to your MCP endpoint, a request that took a very long time, restarts or out-of-memory kills of the Node process, and clients timing out together. After patching, 413 and 400 responses to the same source are the SDK doing its job.
Why do missing limits matter on an MCP endpoint?
An MCP server over Streamable HTTP is, at the network level, a JSON-RPC service. Every tool call an agent makes is a POST whose body is parsed into memory before any tool logic runs. That ordering is the whole problem: the cost of a request is paid before the server can decide whether it deserves an answer. Without a body cap, the attacker chooses how much memory the server spends. Without a batch cap, the attacker chooses how long the event loop stays busy on one request.
Node.js is single-threaded for JavaScript execution, which is why a single long batch can starve other clients rather than merely slow them. The advisory describes exactly that outcome: one long batch blocks the server from serving anyone else. You do not need many connections, which is what makes a flaw like this cheaper to abuse than a classic flood and harder to catch with rate limits that count requests rather than their weight.
The fix is deliberately blunt. The SDK now rejects a body over 4 MiB with 413 before parsing it fully, and a batch over 100 messages with 400. Those numbers are defaults, and the maxRequestBodySize option exists for servers with a real need for more.
How can I confirm the fix works on my server?
Do this against a staging copy, never a production endpoint you depend on. The behaviour below follows from the limits the advisory states; adapt the URL and headers to your own transport setup.
- Confirm the installed version with
npm ls @modelcontextprotocol/sdk(or the 2.x package names above). - Send a POST with a body a little over 4 MiB and expect HTTP 413.
- Send a JSON-RPC array of 101 small messages and expect HTTP 400.
- Send a normal single request and confirm it still succeeds, so you know the limits did not break real traffic.
If step 2 returns 200 or the process grows in memory, your running build is not the version your lockfile says it is. Rebuild the image or redeploy; stale containers are the usual cause.
Hardening checklist for a self-hosted MCP endpoint
The SDK limits are a floor. A server that agents depend on benefits from layers around it:
- a reverse proxy with its own body cap, set below the SDK value;
- authentication before the request reaches the SDK, so anonymous clients cannot reach the parser at all;
- per-client rate limits and a request timeout;
- a memory limit and automatic restart on the container, so an outage is short rather than permanent;
- an alert on 413 and 400 spikes, which indicate someone is probing the limits.
None of this replaces the update. It limits what the next missing-limit bug costs you.
What this means if you run AI coding agents
Most readers of this blog run MCP servers as local stdio processes, and for them this advisory changes nothing. It matters in three cases.
- You built or host an MCP server for a team. A remote MCP server shared by many agents is a single point of failure. A flood or one oversized batch takes the tools away from every developer using it. Treat the endpoint as an internet-facing service: size limits, rate limits, authentication and restart policy.
- You depend on a third-party remote MCP server. You cannot patch it. If it is built on this SDK and unpatched, an outage is possible. Keep a fallback and know which of your agent workflows stall when a tool server is unreachable.
- Your agents run unattended. An agent that loses a tool mid-task may retry, route around the failure or stop. Check what yours does. Our post on MCP server security review covers what to examine before trusting a server, and the practical MCP security guide covers the wider trust boundary.
It also fits a pattern in the ecosystem. The Node.js October security release and the SDK batches this month all land on the same layer: the server code that agents talk to is ordinary network software, and it needs ordinary hardening.
What Beam can and cannot do here
Be clear about the limits. Beam's agent hooks watch what Claude Code, Codex and similar agents do on your machine, and its skill and MCP scan reads configs before you run them. Neither inspects the dependency tree of an MCP server you wrote. They will not tell you that your server is missing a body limit.
What can help is the separate dependency check. beam cve check [DIR] reads lockfiles and matches versions against the AgentBeam CVE database; it exits 0 when clean, 2 when something is found and 1 on error. The post on checking dependencies for known CVEs in CI shows how to wire it in. Whether it flags this advisory depends on the database entry matching your package and versions, so confirm with npm ls. Beam keeps its data on-device; see what Beam keeps local.
Timeline
- October 13, 2026: Beam covers the OAuth credential leak, fixed in 1.31.0.
- October 20, 2026: four further advisories reviewed, fixed in 1.32.0 and 2.3.0 (our post).
- October 15, 2026: GHSA-f897-62hf-6gxq first published by GitHub.
- October 27, 2026: the advisory is added to the GitHub Advisory Database (reviewed), with fixes in sdk 1.30.1, server and node 2.1.0, and hono 2.0.1.
The 1.x fix (1.30.1) is a lower version number than 1.32.0. If you already moved to 1.32.0 for the earlier batch you are above it, but confirm with npm ls rather than assuming; the advisory page is the authority on exact ranges.
Frequently asked questions
Which versions of the MCP TypeScript SDK are affected by GHSA-f897-62hf-6gxq?
@modelcontextprotocol/sdk 1.10.0 through 1.30.0, plus 2.0.0 of @modelcontextprotocol/server, @modelcontextprotocol/node and @modelcontextprotocol/hono. The fixes are sdk 1.30.1, server and node 2.1.0, and hono 2.0.1.
Do I need credentials to exploit it?
No. The advisory rates it AV:N/AC:L/PR:N/UI:N. Any client that can reach the HTTP endpoint can send a large body or a long batch, unless your application authenticates requests before they reach the SDK.
Are stdio MCP servers affected?
No. You are affected if untrusted clients can reach your server over Streamable HTTP. Servers that only run over stdio, the usual setup for a local server started by Claude Code or Codex, are not.
What are the new limits after the update?
Bodies over 4 MiB get HTTP 413 and batches over 100 messages get HTTP 400. If your clients legitimately send more, raise the new maxRequestBodySize option.
Is putting express.json() in front of the SDK enough?
No. The advisory notes that a body parser such as express.json() does not limit batch length, so it does not fully mitigate the issue. A reverse proxy body cap is the suggested stopgap until you can upgrade.
Can Beam detect this?
Not through agent hooks or the skill and MCP config scan, which do not read your own server's dependencies. The separate beam cve check command reads lockfiles and matches versions against the AgentBeam CVE database. Use npm ls as the ground truth.
Related reading
- MCP TypeScript SDK OAuth flaw: a server could collect your client credentials
- MCP TypeScript SDK 1.32.0: four advisories
- MCP server security review
- Practical MCP security guide
- Primary source: GHSA-f897-62hf-6gxq on GitHub and the MCP TypeScript SDK repository
Versions and advisory details are accurate as of October 27, 2026. Check the advisory page for later changes.