EUVD-2026-96988
GHSA-645v-p22p-m3jx
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessOpen WebSocket to MCP server
-
DeliverySend frame header declaring ~2 GiB payload
-
ExploitServer allocates oversized heap buffer
-
ExecutionRepeat over few connections
-
ImpactMemory exhausted, service denial
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A06:2025 - Insecure Design
ASVS 5.0
V2 - Validation and Business Logic Resource allocation limits
MITRE ATT&CK
1 technique across 1 tactic: Impact The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | The MCP server must be deployed using the Kotlin SDK's WebSocket transport - specifically the Application.mcpWebSocket extension that installs Ktor WebSockets - and reachable by the attacking client; servers using stdio or non-WebSocket transports are not affected. No authentication, user interaction, or non-default toggle is required beyond enabling the WebSocket transport itself, because the vulnerable configuration (absence of a maxFrameSize limit) is the installed default. The practical limiting factor is exposure: exploitation requires network reachability to a WebSocket endpoint running an affected version (≤ 0.15.0), so servers restricted to trusted/internal clients or not exposing the WebSocket transport face materially lower risk. |
| Impact | All signals point to a genuine but single-dimension (availability-only) risk. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) describes the worst-case reachability profile: remote, network-based, low complexity, no authentication, and no user interaction - meaning any client that can open a WebSocket to the server can trigger it. However, the impact is strictly VA:H with VC:N/VI:N - no confidentiality or integrity loss, pure denial of service - so the 8.7 'High' rating is driven entirely by availability. No EPSS score, CISA KEV listing, or SSVC decision data was provided in the input, so exploitation-likelihood and automatability cannot be quantified from the signals given; their absence is NOT evidence of low risk, merely missing telemetry. A vendor advisory (VulnCheck) and a detailed public technical writeup (hackmd) exist, which lowers the barrier to reproducing the issue, but no packaged exploit code was supplied in the input. Net assessment: a legitimate priority for anyone running the MCP Kotlin SDK WebSocket transport exposed to untrusted clients, but it is a resource-exhaustion DoS, not a code-execution or data-breach bug, and should be triaged accordingly below RCE-class issues. |
| Exploit ScenarioDerived | A remote client opens a WebSocket connection to an MCP server built on the Kotlin SDK's Application.mcpWebSocket transport and sends a small WebSocket frame header declaring a payload size near 2 GiB. The Ktor WebSocket layer, configured without a maxFrameSize limit, attempts to allocate that buffer on the heap; a few such connections exhaust available memory and crash or hang the server (OutOfMemoryError / denial of service). A public technical writeup describing the flaw exists, but no weaponized exploit was provided in the input. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 11, 2026
Memory exhaustion in the Model Context Protocol (MCP) Kotlin SDK through version 0.15.0 allows unauthenticated remote clients to drive a server into denial of service by sending WebSocket frames whose headers declare payloads approaching 2 GiB, forcing the server to attempt huge heap allocations before any frame body is received. The flaw lives in the SDK's Application.mcpWebSocket extension, which installs Ktor WebSockets without a maxFrameSize limit, and because that unprotected configuration is the installed default, no special toggle or misconfiguration is required. Impact is availability-only (no confidentiality or integrity loss), the practical limiting factor is network reachability to an exposed WebSocket endpoint running an affected version, and no public exploit code or active exploitation has been identified at time of analysis.
RemediationAI
No vendor-released patch has been identified at time of analysis, so operators must rely on compensating controls. The most direct mitigation is to reinstall the Ktor WebSockets plugin with an explicit maxFrameSize (and, where available, a bounded read/ping timeout) in the WebSocketMcpKtorServerExtensions configuration so oversized frames are rejected rather than buffered - the trade-off is that legitimate large MCP payloads above the chosen limit will be refused, so the value must be set above the expected maximum message size. If the WebSocket transport is not required, switch to the stdio transport, which removes the attack surface entirely; if WebSocket is required, restrict reachability of the WebSocket endpoint to trusted networks or authenticated reverse proxies (network ACLs, mTLS, or an authenticating gateway), accepting that this limits legitimate remote clients. Running the server under a container or cgroup memory cap and with a tuned JVM/GraalVM heap ceiling will not prevent individual huge allocations but will fail fast and limit blast radius, at the cost of earlier OOM termination. Rate-limiting or capping concurrent WebSocket connections per client also reduces the number of parallel allocation attempts. Monitor for unusually large WebSocket frame headers or abrupt heap growth as a detection signal. Consult the VulnCheck advisory (https://www.vulncheck.com/advisories/mcp-kotlin-sdk-through-0.15.0-memory-exhaustion-via-application-mcpwebsocket) and the upstream project (https://github.com/modelcontextprotocol/kotlin-sdk) for any fix or updated release as it becomes available.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The MCP Kotlin SDK implements the Model Context Protocol over multiple transports, including a WebSocket transport built on Ktor's server WebSockets plugin. In the vulnerable code paths (WebSocketMcpKtorServerExtensions.kt and WebSocketMcpTransport.kt, both at tag 0.15.0), the Ktor WebSocket installation omits the maxFrameSize parameter, so Ktor falls back to its permissive default and trusts the length field in the WebSocket frame header when sizing the buffer for an incoming frame. WebSocket framing places a 64-bit payload-length field in the frame header, which is only a few bytes on the wire, meaning a client can cheaply advertise a payload close to 2 GiB and cause the server to allocate that much heap upfront - a classic amplification of a tiny request into a massive allocation. This maps to CWE-770 (Allocation of Resources Without Limits or Throttling): the root cause is the absence of a bound on a resource (heap) that an untrusted peer controls, rather than a parsing or memory-safety bug. The affected component is identified by CPE cpe:2.3:a:modelcontextprotocol:kotlin-sdk, covering all builds up to and including 0.15.0.
Know when Kotlin Sdk gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
Remote unauthenticated WebSocket client triggers the allocation with no interaction (AV:N/AC:L/PR:N/UI:N); impact is availability-only memory exhaustion (A:H, C:N/I:N), no scope change.
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
DescriptionCVE.org
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.
Executive ViewAI
The MCP Kotlin SDK, a component used in AI model-context services, has a high-severity availability flaw in versions through 0.15.0 that can let remote clients exhaust server memory and cause denial of service, potentially disrupting dependent applications and business workflows. Because the risky WebSocket configuration is the default, affected teams may be exposed simply by deploying an exposed endpoint, and no public exploit identified at time of analysis does not reduce the need for immediate containment and vendor tracking.
Restrict network access to exposed WebSocket endpoints, enforce maxFrameSize and request/rate limits at a reverse proxy, WAF, or load balancer, monitor server memory and connection behavior, and isolate or disable affected MCP Kotlin SDK services until a vendor-released patch is available.
Threat Intelligence Overview
NVD
CVE.org
EPSS
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Denial of Service attacks render applications or systems unavailable by overwhelming resources or triggering failure conditions.
Exploit-DB