Kotlin SDK discloses two Streamable HTTP denial-of-service records, one unauthenticated, both fixed nine weeks earlier

The official Kotlin SDK published two security advisories on 2026-09-03, both against its Streamable HTTP transport and both describing the same failure in opposite directions: a size limit that does not hold.

CVE-2026-63658, rated high at CVSS 7.5, is the server-side case and needs no credentials. The transport enforces a request body limit by checking the size before reading, but a request sent with Transfer-Encoding: chunked carries no Content-Length to check, and neither does HTTP/2. The guard is skipped, receiveText() buffers the whole attacker-supplied body, and the JVM heap is exhausted. The advisory also records that SSEServerTransport.handlePostMessage() has the same flaw with no size limit at all.

CVE-2026-63657, medium at 6.5, is the client-side mirror. A malicious or compromised MCP server can stream data: lines forever without ever sending the blank line that terminates an SSE event, so StreamableHttpClientTransport accumulates the fragments in memory waiting for an event that never arrives.

Both affect 0.13.0 and earlier and were fixed in 0.14.0, released 2026-06-30, which puts the records nine weeks behind the fix; the current release is 0.15.0. Neither CVE had a populated record at cveawg.mitre.org when checked on 2026-09-03, so the repository advisories are the primary evidence for both.

The pattern is now hard to miss. In under a month, unbounded-read defects in HTTP transports have been disclosed against five official SDKs: the PHP SDK's client-side SSE buffer, the Java SDK bounding its unbounded HTTP reads, the Python SDK extending its body limit to SSE and OAuth endpoints, and now the Kotlin SDK in both directions at once. The 2026-07-28 revision made Streamable HTTP the primary binding, and each SDK has had to learn separately where its own reads were unbounded.