mcp-go Buffers Every Streamable HTTP POST Into Memory, and There Is Still No Patch

The Go implementation of the Model Context Protocol has a denial-of-service hole that still lacks a named fix. NVD published CVE-2026-108859 on October 11, 2026 at 14:17 UTC (7:47 PM IST), and GitHub mirrored it the same day as GHSA-c673-ppxx-9wvj. The advisory covers mark3labs/mcp-go through version 1.2.1. CVSS 4.0 scores it 8.7 High; CVSS 3.1 scores it 7.5 High with the vector AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H. Neither record lists a patched release.

mcp-go is one of the main SDKs for wiring MCP servers in Go. The project has more than 9,000 GitHub stars. Any deployment that exposes its Streamable HTTP transport to untrusted traffic is in scope for the finding.

Where the body is swallowed whole

The vulnerable path sits in StreamableHTTPServer.ServeHTTP inside server/streamable_http.go. For every POST with a non-nil body, the handler calls io.ReadAll(r.Body) and stores the result in a byte slice before content-type checks or JSON parsing run. Go’s net/http server does not impose a default body-size limit, and the file contains neither http.MaxBytesReader nor io.LimitReader at the reviewed revisions.

The researcher’s write-up pins the same pattern at release tag v1.2.1 (commit 90d247ed) and at main HEAD shortly after disclosure. Content-type validation and JSON parsing happen later, inside handlePost. By then the bytes are already resident in process memory.

The convenience listener makes the gap worse for default setups. Start(addr) builds an http.Server with only Addr and Handler set. There is no ReadTimeout, no MaxHeaderBytes, and no body cap. A peer that can reach the endpoint can send one oversized POST or many concurrent ones and force the process toward memory exhaustion or an out-of-memory kill.

What is and is not at stake

The impact is availability only. The CVSS vectors rate confidentiality and integrity as none. An attacker does not need credentials or user interaction. They only need network reachability to the Streamable HTTP endpoint.

That profile matters for how teams triage. An MCP server bound to a private mesh and fronted by a reverse proxy with request-body limits is in a different risk class from one listening on a public address with the stock Start helper. Red Hat’s customer note for the same CVE frames the issue the same way: applications that expose the streamable HTTP endpoint to untrusted traffic can be terminated by out-of-memory errors when processing oversized payloads.

There is no claim of remote code execution, authentication bypass, or data theft in the NVD description. The CWE assignment is CWE-770, Allocation of Resources Without Limits or Throttling. Credit on the CVE record goes to hieuPenguinnn.

Why “upgrade” is not an answer yet

As of the advisory text, Dependabot alerts are not available because the entry has no supported-ecosystem package with both an affected range and a fixed version. The newest published tag on the repository remains v1.2.1. Operators who pull github.com/mark3labs/mcp-go@v1.2.1 or earlier are still on an affected tree.

Until a release that wraps the POST body in a size-limited reader and hardens the default server timeouts ships, mitigations are infrastructure-side. Put a reverse proxy or API gateway in front of the Streamable HTTP listener and enforce a hard maximum request body. Reject requests that exceed that ceiling before they reach the Go process. Prefer binding the server to trusted networks only. If the deployment can use stdio or another local transport instead of Streamable HTTP on an open interface, that shrinks the attack surface immediately.

Teams that vendor mcp-go as a library should treat the unbounded io.ReadAll as a local patch candidate: wrap r.Body with http.MaxBytesReader before the full read, fail closed on oversize input, and set read deadlines on the http.Server. Those changes are defensive until upstream tags a fixed version.

Part of a wider MCP hardening week

October 10 and 11 saw a cluster of agent and MCP advisories land in NVD, several of them still without vendor patches. mcp-go stands out in that batch because the SDK is widely reused and because the failure mode is simple: buffer first, validate later. For Go MCP servers that must stay online under untrusted load, body limits are no longer optional plumbing. They are the difference between a protocol endpoint and an open memory sink.