Description

The Model Context Protocol TypeScript SDK provides TypeScript client and server implementations of the Model Context Protocol. From 1.3.0 until 1.32.0 in @modelcontextprotocol/sdk and from 2.0.0 until 2.3.0 in @modelcontextprotocol/server, HTTP servers did not enforce a limit on the number of array elements and object keys validated in one request. The affected surface is validation of HTTP requests containing arrays or object keys. The trigger is an array-element or object-key validation workload large enough to exhaust memory while remaining within the request size limit. A single request within the default 4 MiB limit can terminate the process with JavaScript heap exhaustion. No credentials are required unless the application authenticates before SDK processing. Tools accepting arrays or records carry the greatest risk. stdio-only servers do not expose the HTTP request path. Upgrading alone does not enable the new validation bound. Operators must configure both a tool-input element bound and an appropriate request body size limit. This issue is fixed in @modelcontextprotocol/sdk 1.32.0 and @modelcontextprotocol/server 2.3.0.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-11-05T22:17:45.457Z",
  "pubdate": "2026-11-05T22:17:45.457Z",
  "executiveSummary": "The Model Context Protocol (MCP) TypeScript SDK is susceptible to a denial-of-service (DoS) condition caused by insufficient validation of HTTP request structures. Specifically, the SDK fails to impose limits on the number of array elements and object keys within a single request, enabling attackers to trigger JavaScript heap exhaustion through specially crafted payloads.\nThe vulnerability affects @modelcontextprotocol/sdk versions 1.3.0 through 1.32.0 and @modelcontextprotocol/server versions 2.0.0 through 2.3.0. Exploitation does not require authentication, provided the application processes the request before verifying credentials, and can be executed within the default 4 MiB HTTP request body limit. The primary impact is the termination of the server process, leading to service disruption. Mitigation requires updating to the patched versions and explicitly configuring strict validation bounds for tool-input elements alongside robust HTTP request size limitations.",
  "technicalDetails": "The root cause of this vulnerability lies in the lack of depth-limiting or count-limiting mechanisms during the deserialization and validation phase of incoming HTTP requests. When the SDK processes an incoming request, it iterates over structures—specifically arrays and object keys—without imposing a maximum threshold on the volume of elements or keys. By crafting a request payload that maintains a small overall byte size (staying within the default 4 MiB limit) but contains an extremely large number of nested or flat elements, an attacker can force the JavaScript engine to allocate excessive memory for the validation objects.\nThe exploitation flow proceeds as follows: An attacker sends a malicious HTTP POST request to the MCP server endpoint. Because the validation logic does not restrict the number of keys or array items, the SDK attempts to parse and validate the entirety of the payload in memory. If the payload is sufficiently complex or dense in terms of object/array count, the resulting allocation triggers a JavaScript heap exhaustion event. This causes the Node.js process to crash, effectively resulting in a denial-of-service for all users of that server instance.\nThe vulnerable component is the HTTP request validation layer within the SDK. While stdio-based implementations are not affected due to the absence of the HTTP request path, any server exposing an HTTP transport is potentially at risk. The vulnerability is particularly acute for servers that utilize tool-input schema definitions, as these schemas are dynamically processed against the provided input at runtime.\nBecause the vulnerability occurs during the processing stage, exploitation generally does not require authentication unless the authentication check is explicitly implemented to execute prior to any SDK-based request parsing. An attacker on the network can transmit these payloads without specific privileges, making this a critical availability risk for exposed MCP server instances.\nPost-exploitation, the process is terminated, requiring external intervention (such as an orchestrator restart) to restore service. Since upgrading the library alone does not automatically resolve the risk, operators must also implement defensive configuration bounds. These bounds serve as circuit breakers for memory consumption, ensuring that even if a request is valid according to size constraints, it is rejected if the structure complexity exceeds reasonable architectural limits."
}