Description

mcp-go through 1.2.1 contains a denial of service vulnerability in StreamableHTTPServer.ServeHTTP that allows remote unauthenticated attackers to exhaust memory by sending oversized POST bodies. Attackers can send arbitrarily large or many concurrent POST requests, read fully via io.ReadAll before validation, to degrade or OOM-kill the server process.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-10-11T14:17:05.780Z",
  "pubdate": "2026-10-11T14:17:05.780Z",
  "executiveSummary": "The mcp-go library, specifically versions through 1.2.1, is susceptible to a denial-of-service (DoS) vulnerability located within the StreamableHTTPServer.ServeHTTP function. This issue arises from improper request body handling, where the server consumes arbitrary amounts of memory while processing incoming POST requests.\nThe vulnerability allows remote, unauthenticated attackers to trigger an out-of-memory (OOM) condition or significant performance degradation by sending either singular, excessively large POST payloads or a high volume of concurrent POST requests. Because the implementation utilizes io.ReadAll to buffer the entire request body into memory before performing any validation or constraint checks, the server is left vulnerable to resource exhaustion.\nThe impact is critical, as it allows an attacker to effectively crash the host process or render the service unavailable, leading to service disruption. Exploitation requires only basic network connectivity to the affected HTTP server, as no authentication or specific privileges are necessary to trigger the vulnerable code path. The risk is significant for any production environment relying on mcp-go for handling HTTP traffic without upstream request body limitations or proxy-based protections.",
  "technicalDetails": "The vulnerability resides within the StreamableHTTPServer.ServeHTTP function of the mcp-go library, which is responsible for processing incoming HTTP traffic. The root cause of the vulnerability is the unconditional invocation of io.ReadAll on the request body within the HTTP handler before any form of request validation, such as Content-Length verification or streaming input processing, occurs.\nIn the Go programming language, io.ReadAll reads the entirety of the provided io.Reader into an allocated byte slice in memory. Because the vulnerable code lacks a restrictive wrapper (such as an io.LimitReader) or a pre-check against the Content-Length header, the server implicitly trusts the client to provide a body of a reasonable size. An attacker can exploit this by initiating a POST request with an extremely large body or by flooding the server with multiple concurrent requests that trigger the allocation of large memory blocks.\nThe attack flow follows a predictable pattern: first, the attacker establishes a TCP connection to the target instance running mcp-go. Second, the attacker issues a specially crafted HTTP POST request. The server's ServeHTTP implementation then proceeds to read the incoming request body using io.ReadAll. Because the operation is blocking and memory-intensive, the server process allocates heap memory proportionally to the size of the incoming data.\nBy sending large payloads, the attacker forces the Go runtime to perform frequent and massive heap allocations. If multiple such requests are sent concurrently, the memory consumption quickly escalates, leading to extreme memory pressure. This results in either the application reaching its memory limit, triggering an OOM-kill event by the operating system kernel, or the Go garbage collector (GC) becoming overwhelmed by the memory pressure, effectively halting the application's ability to respond to legitimate traffic.\nThis vulnerability is classified as a memory exhaustion-based denial-of-service. It is particularly dangerous because it bypasses application-level authentication mechanisms, as the vulnerability is triggered during the early stages of request processing before any authorization logic is executed. Any public-facing instance of mcp-go through version 1.2.1 is exposed to this vector if it does not employ external rate limiting or request size restrictions at the infrastructure level (e.g., via a reverse proxy or load balancer)."
}