CVE-2026-53937: MCP Kotlin SDK DOS Vulnerability

CVE-2026-53937 Overview

CVE-2026-53937 is an unbounded memory allocation vulnerability in the Model Context Protocol (MCP) Kotlin SDK, versions 0.7.0 through 0.12.0. The flaw resides in ReadBuffer.append within kotlin-sdk-core/src/commonMain/kotlin/io/modelcontextprotocol/kotlin/sdk/shared/ReadBuffer.kt, which writes stdio chunks into a kotlinx.io.Buffer without any size cap. A peer that streams bytes without ever transmitting a newline (0x0a) causes the buffer to grow until the JVM or host process is OOM-killed. Version 0.13.0 introduces a 16 MiB frame cap enforced through a new TooLongFrameException. The vulnerability is tracked as an uncontrolled resource consumption issue [CWE-400].

Critical Impact
A remote pre-authentication attacker who controls stdin input to an MCP Kotlin SDK stdio transport can force process termination through memory exhaustion, disrupting availability of any MCP server bridged to untrusted network input.

Affected Products

MCP Kotlin SDK versions 0.7.0 through 0.12.0
Applications using StdioServerTransport from the affected SDK versions
Applications using StdioClientTransport from the affected SDK versions

Discovery Timeline

2026-09-09 - CVE-2026-53937 published to the National Vulnerability Database
2026-09-09 - Last updated in NVD database

Technical Details for CVE-2026-53937

Vulnerability Analysis

The MCP Kotlin SDK frames JSON-RPC messages from a continuous stdio byte stream by scanning for newline delimiters. The ReadBuffer class accumulates incoming chunks into an in-memory kotlinx.io.Buffer and only extracts a frame when it observes a \n byte. Without a delimiter, no framing occurs and no memory is released. This design converts any newline-free byte stream into an uncontrolled growth condition.

Both StdioServerTransport and StdioClientTransport amplify the issue. Each transport queues raw chunks through kotlinx.coroutines.channels.Channel<ByteArray>(Channel.UNLIMITED) and forwards them to readBuffer.append(chunk) without backpressure or an upper bound. A slow-drip attacker or a fast bulk-write attacker can both drive the JVM heap to exhaustion.

Root Cause

The root cause is missing input validation on frame size. ReadBuffer.append trusts that a well-formed peer will eventually send a newline. The transport layer compounds the defect by choosing Channel.UNLIMITED, which removes the natural backpressure a bounded channel would provide. Neither layer enforces a maximum in-flight byte count.

Attack Vector

Exploitation requires an attacker-influenced producer feeding stdin of a process using the vulnerable SDK. Common deployment patterns exposing this vector include host programs that exec an MCP server as a subprocess and pipe network bytes through, and sidecar wrappers that proxy HTTP payloads into the stdio transport. The attacker sends arbitrary bytes and withholds the \n delimiter until the target process is terminated by the OOM killer.

text

// Patch excerpt: kotlin-sdk-core/src/commonMain/kotlin/io/modelcontextprotocol/kotlin/sdk/shared/ReadBuffer.kt
 import io.modelcontextprotocol.kotlin.sdk.types.JSONRPCMessage
 import io.modelcontextprotocol.kotlin.sdk.types.McpJson
 import kotlinx.io.Buffer
+import kotlinx.io.IOException
 import kotlinx.io.indexOf
 import kotlinx.io.readString

 /**
  * Buffers a continuous stdio stream into discrete JSON-RPC messages.
+ *
+ * A single newline-terminated frame may not exceed an internal size cap (16 MiB): a peer that streams
+ * bytes without ever sending a newline triggers a [TooLongFrameException] from [readMessage] instead
+ * of growing the buffer without bound. A non-positive cap disables the check.
  */
-public class ReadBuffer {
+public class ReadBuffer internal constructor(private val maxFrameSize: Int) {
+
+    public constructor() : this(DEFAULT_MAX_FRAME_SIZE)
+
+    internal companion object {
+        internal const val DEFAULT_MAX_FRAME_SIZE: Int = 16 * 1024 * 1024
+    }

Source: GitHub Commit 6e6f805

Detection Methods for CVE-2026-53937

Indicators of Compromise

Java Virtual Machine OutOfMemoryError crashes in processes hosting MCP Kotlin SDK stdio transports
Host operating system OOM-killer log entries targeting MCP server processes or their parent host applications
Sudden resident set size (RSS) growth in Kotlin/JVM processes bound to stdin from network-fed producers
Absence of TooLongFrameException events combined with sustained stdio ingress on vulnerable versions

Detection Strategies

Inventory dependency manifests (build.gradle, build.gradle.kts, pom.xml) for io.modelcontextprotocol:kotlin-sdk-core versions in the 0.7.0 through 0.12.0 range
Instrument stdio-fed MCP processes with JVM memory metrics and alert on rapid heap growth without corresponding message-processing throughput
Correlate parent-process network I/O with child MCP process memory usage to identify byte streams lacking newline delimiters

Monitoring Recommendations

Enable JVM garbage collection and heap telemetry export from all MCP Kotlin SDK deployments
Monitor Linux dmesg and /var/log/messages for OOM-killer entries referencing MCP server binaries
Track process restart frequency for MCP subprocesses spawned by host applications to detect availability impact

How to Mitigate CVE-2026-53937

Immediate Actions Required

Upgrade the io.modelcontextprotocol:kotlin-sdk-core dependency to version 0.13.0 or later across all builds
Audit deployments where MCP stdio transports receive input sourced from network peers or untrusted processes
Restart any long-running MCP host processes after upgrading to ensure the patched ReadBuffer is loaded

Patch Information

The fix landed in MCP Kotlin SDK release 0.13.0 via commit 6e6f805. The patch introduces a DEFAULT_MAX_FRAME_SIZE of 16 MiB and raises a TooLongFrameException when a single unterminated frame exceeds the cap. Full advisory details are published as GHSA-74gp-qhv5-v493.

Workarounds

Interpose a bounded framing proxy between untrusted producers and the MCP stdio transport that enforces a maximum bytes-per-frame limit
Constrain the MCP subprocess with operating system resource limits (for example, ulimit -v or systemd MemoryMax) to contain OOM impact
Restrict which callers can pipe data into MCP stdio by isolating the transport behind an authenticated wrapper

bash

# Gradle dependency upgrade
dependencies {
    implementation("io.modelcontextprotocol:kotlin-sdk-core:0.13.0")
}

# Optional systemd hardening for MCP host service
# /etc/systemd/system/mcp-host.service.d/limits.conf
[Service]
MemoryMax=512M
MemoryHigh=384M