CVE-2026-108714 in kotlin-sdk
Summary
by MITRE • 10/11/2026
MCP Kotlin SDK through 0.15.0 contains an uncontrolled memory allocation vulnerability that allows remote clients to exhaust server memory because Application.mcpWebSocket installs Ktor WebSockets without a maxFrameSize limit. Attackers can send small frame headers declaring payloads near 2 GiB over one or a few connections, forcing huge heap allocations and causing denial of service.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/11/2026
The MCP Kotlin SDK version 0.15.0 contains a critical uncontrolled memory allocation vulnerability within its WebSocket implementation that poses a significant risk to server stability and availability. This flaw stems from the configuration of Ktor WebSockets, which are installed without enforcing a maximum frame size limit via the Application.mcpWebSocket module. In standard WebSocket implementations, the maxFrameSize parameter serves as a crucial safeguard by defining the upper boundary for the payload data that can be processed in a single operation. By omitting this constraint, the server accepts any incoming message frame regardless of its declared or actual size, creating an environment where resource consumption is entirely dependent on client input rather than predefined security policies.
The technical mechanism of exploitation relies on the structure of WebSocket frames, which include headers that specify the length and type of the subsequent payload data. An attacker can craft malicious requests containing small header sections but declaring a payload size approaching two gigabytes. When these malformed or oversized frames are received by the vulnerable server, the underlying Ktor library attempts to allocate heap memory sufficient to hold the entire declared payload before any validation or processing occurs. This immediate and massive allocation of resources is triggered even if the actual data transmitted does not match the header declaration, as many implementations pre-allocate buffers based on the stated size for efficiency. Consequently, a single connection can trigger a substantial drain on available system memory.
The operational impact of this vulnerability is severe, primarily manifesting as a denial of service condition. Because each malicious request forces the server to allocate near two gigabytes of heap space, an attacker does not need to send large volumes of data over time; instead, they can exhaust server resources with just one or a few connections from different sources if distributed across multiple threads or processes. This rapid memory exhaustion leads to out-of-memory errors, causing the application to crash or become unresponsive. Legitimate users are subsequently denied access to the service as the system fails to process valid requests due to resource starvation. The lack of rate limiting combined with this allocation flaw makes it particularly easy for adversaries to disrupt service availability without requiring complex payload construction techniques beyond standard WebSocket framing rules.
From a classification perspective, this vulnerability aligns closely with CWE-789: Uncontrolled Memory Allocation and CWE-400: Uncontrolled Resource Consumption. It also maps to the MITRE ATT&CK technique T1499: Endpoint Denial of Service, specifically under methods involving resource exhaustion through application layer attacks. The absence of input validation regarding message size is a fundamental design oversight that violates best practices for secure network service configuration. To mitigate this risk, developers must immediately update the MCP Kotlin SDK to a patched version where maxFrameSize is explicitly configured with an appropriate limit based on expected business requirements. Additionally, implementing server-side rate limiting and monitoring memory usage metrics can provide early detection of such abuse patterns while patches are being deployed.