Official Java SDK caps HTTP reads in both directions after two resource-exhaustion advisories

The Model Context Protocol Java SDK published two advisories on 2026-08-19, one for its server transports and one for its client transports, and shipped the fixes across three release lines the same afternoon. Both are classed CWE-770, allocation of resources without limits, and neither carries a CVE ID.

The server-side advisory, GHSA-4x8c-5vv7-973f, is rated high at CVSS 7.5. All three Servlet-based HTTP transports in mcp-core (Streamable HTTP, Stateless Streamable HTTP, and SSE) read the incoming request body into memory in a loop with no maximum size, and none of them checked the Content-Length header. The advisory states that a client using chunked transfer encoding could therefore stream an arbitrarily large body past any size check a deployment thought it had, and that one unauthenticated POST was enough to exhaust the heap and raise OutOfMemoryError. It names two mitigating factors: the transports' existing Origin and Host allow-list, and any authentication implemented outside the SDK, both of which read headers and can reject a request before the body is read.

The client-side advisory, GHSA-5q7x-232h-f834, is rated medium at CVSS 6.5 and points the same weakness the other way. Both HTTP client transports parse Server-Sent Events through one shared subscriber, ResponseSubscribers.SseLineSubscriber, which accumulates every data: line into a StringBuilder and dispatches only when it sees a blank line. A server that never sends that blank line can grow the client's heap without limit at almost no cost to itself. Multi-line data: fields are valid SSE and are meant to be concatenated; what was missing was any cap. The advisory is explicit that the SDK had no equivalent of the frame-size limit its sibling SDKs carry, naming ReadBuffer.DEFAULT_MAX_FRAME_SIZE as the analogue that did not exist here. It affects both the long-lived GET event stream and inline SSE returned on a POST, because both funnel through the same subscriber. There is no code execution in either advisory.

The remediation is version-line specific: 2.0.1, 1.1.4, or 0.18.4, matching whichever line a deployment tracks. Pull request #1102 bounded the HTTP reads and #1103 did the same for stdio, which no advisory covers. The merges landed at 12:41Z and 12:53Z, the three releases between 13:44Z and 13:47Z, and the advisories at 14:26Z. Deployments that cannot upgrade are told to put a reverse proxy or gateway enforcing a request-body size limit in front of the server.

Version 2.0.1 also carries spec-conformance work beyond the security fixes: SSE event classification now follows the specification when the event field is missing, pagination stops on empty cursors, stateless servers behave correctly on unregistered handlers, and the release upgrades the conformance suite to 0.1.16 with Spring AI conformance at 2.0.0 GA. The 1.1.4 and 0.18.4 releases each contain nothing but the backported read bound.