MCP Kotlin SDK Unbounded stdio Buffer Denial of Service
First seen Sep 10, 2026 · Updated Sep 10, 2026 · CVSS 6.2
The MCP Kotlin SDK's stdio transport buffers incoming bytes with no size limit and only flushes frames on a newline delimiter, allowing a malicious or malformed peer to stream endless newline-free data and exhaust JVM memory until the host process is OOM-killed. This is a remote, pre-authentication denial-of-service issue affecting any deployment where stdin to the MCP server is fed by an untrusted producer, such as a proxy or wrapper bridging network input to stdio. The vendor has released version 0.13.0 with a fix.
Technical Analysis
The vulnerability lies in `ReadBuffer.append`, which appends every received chunk into a `kotlinx.io.Buffer` without any cap, only extracting a frame when a `\n` byte appears in the stream. Both `StdioServerTransport` and `StdioClientTransport` compound the issue by queuing raw bytes through an unlimited-capacity coroutine channel before calling `append`, meaning there is no backpressure mechanism anywhere in the pipeline. An attacker who can influence bytes reaching the process's stdin — for example via a sidecar or gateway that proxies untrusted network traffic into the stdio transport — can simply withhold newline characters indefinitely, causing continuous buffer growth until the JVM heap is exhausted and the process is killed by the OS. This crosses a trust boundary because stdio transports are traditionally assumed to be local/trusted, but many real-world MCP deployments bridge stdio to network-facing components, effectively giving remote, unauthenticated attackers a crash primitive against the MCP server or client process.
Affected Systems
MCP Kotlin SDK; protocols: MCP
Detection Signatures
- Monitor MCP host/subprocess memory usage for continuous, unbounded growth correlated with stdio input activity
- Log stdin byte throughput without corresponding newline-delimited frame completions over extended windows
- Alert on JVM processes hosting MCP servers being OOM-killed unexpectedly
- Inspect any proxy/sidecar components that pipe network data into MCP stdio transports for lack of size limits or timeouts
Remediation Steps
- 1
Upgrade MCP Kotlin SDK
Update to version 0.13.0 or later, which fixes the unbounded buffer growth in ReadBuffer.append.
- 2
Enforce buffer size limits
If running an older version, wrap or patch the stdio transport to cap total buffered bytes and reject/close connections that exceed a reasonable frame size without a newline.
- 3
Add backpressure to stdio channels
Replace unlimited-capacity channels with bounded channels and apply flow control between the byte reader and the buffer append logic.
- 4
Isolate untrusted stdio bridges
Avoid directly piping untrusted network input into MCP stdio transports; if required, place a hardened proxy in front that enforces size and timeout limits before data reaches the SDK.
- 5
Apply process resource limits
Run MCP server processes under memory/resource limits (e.g., cgroups, JVM heap caps) so a single malicious peer cannot exhaust host-wide resources.
CVE / Advisory IDs
Industries Most Exposed
Respond to this threat
Pro subscribers get a full AI-generated incident-response playbook for this threat — detection, containment, eradication, and recovery steps — plus an unlimited AI Threat Advisor for questions about your environment.