The Dangers of MCP Servers and the Streamable-HTTP Blind Spot: A Deep Dive for Security Researchers

Introduction: The Next-Gen Protocols No One Is Testing

In the world of security research, familiar protocols and server types - classic HTTP, RESTful APIs, and legacy backends - have long attracted the lion’s share of testing and tooling. Over years of relentless analysis, these systems have become both battle-hardened and well-understood, and the security industry has built a robust ecosystem around them: scanners, fuzzers, code analyzers, and more. But the landscape is evolving, and so are the protocols underpinning our most innovative web applications and services.

Among these next-generation components, MCP servers - often relying on custom, persistent, and highly performant communication channels built atop "streamable-HTTP" concepts - are emerging as a critical, yet overlooked, layer in distributed systems. From real-time analytics pipelines and financial trading platforms to IoT control planes and multiplayer game backends, MCP servers offer capabilities that traditional request/response web servers simply cannot match.

But with new power comes new risk. The same flexibility and performance optimizations that make MCP attractive also introduce a fundamentally different attack surface - one that traditional security testing tools are not equipped to handle. As researchers and defenders, our collective attention must shift to these blind spots before they become the next major vector for large-scale exploitation.

In this article, we’ll dissect MCP and streamable-HTTP at a protocol level, analyze their security implications, illustrate how conventional tools fail to expose the risks, and show how Penzzer’s MCP Inspector was engineered to uncover vulnerabilities where no one else is looking.

‍

Understanding MCP Servers

What is MCP?

MCP, or Meta Content Protocol, is a design pattern and protocol family used to facilitate persistent, multiplexed, and context-rich communication between clients and servers. Unlike conventional web servers, which treat every HTTP request as an independent transaction, MCP servers enable ongoing dialogs - streams - where data can flow bidirectionally without the overhead of establishing new connections or sessions for each exchange.

‍

Where is MCP Used?

MCP’s appeal lies in its versatility. You’ll find MCP servers embedded in:

• Streaming data platforms: Feeding real-time metrics, telemetry, or sensor data between edge devices and central analytics backends.
• Custom APIs: Powering systems where classic REST or GraphQL APIs are too limiting due to latency or volume requirements.
• Message brokers and event buses: Offering a blend of pub/sub messaging and request/response patterns within the same persistent channel.
• Financial and trading systems: Delivering time-sensitive market data or order routing with minimal round-trip delays.
• IoT control panels: Managing persistent device connections for low-latency command and monitoring.

‍

MCP vs. Traditional Web Servers

MCP servers break from the request/response mold in several key ways:

• Stateful, Long-Lived Connections: Sessions are established once and may persist for hours or days.
• Protocol Multiplexing: Multiple logical conversations can share a single physical connection.
• Contextual Interactions: Each “message” in the stream may carry its own metadata, enabling sophisticated negotiation and adaptation on the fly.
• High Performance: Reduced connection churn and overhead enable systems to scale to millions of concurrent streams.

These advantages have driven widespread MCP adoption in performance-critical applications - but have also led to a new class of security challenges that demand closer scrutiny.

‍

Deep Dive: Streamable-HTTP Architecture and Protocol Design

Why "Streamable"?

Traditional HTTP was never designed for real-time, persistent communication. Its origins as a stateless, transactional protocol suited the early web, but fell short in the face of modern demands for live collaboration, streaming media, and high-throughput data flows. Streamable-HTTP represents a set of architectural patterns and protocol extensions that adapt HTTP for these use cases by introducing persistent, multiplexed streams atop familiar web transport mechanisms.

‍

Underlying Transport

MCP servers are usually built on top of HTTP/1.1, leveraging its persistent connection ("keep-alive") capability to create long-lived channels between clients and servers. Unlike modern real-time protocols such as WebSockets or HTTP/2/HTTP/3, MCP does not natively support protocol-level multiplexing or binary streams. Instead, all multiplexing and stream management occur at the application layer on top of a plain HTTP/1.1 POST request that remains open for the lifetime of the connection.

• HTTP/1.1 Persistent Connections: MCP clients initiate a POST (or sometimes GET) request to the server and keep the connection open indefinitely. Data flows from client to server (or sometimes bidirectionally), but always within the constraints of HTTP/1.1 semantics.
• Custom Application Framing: Since HTTP/1.1 does not provide framing for streaming data beyond the initial request/response, MCP introduces its own message boundaries (e.g., length-prefixed blocks, delimiters, or envelope formats) so each side can parse messages as they arrive.
• No Native Multiplexing: Unlike HTTP/2, which supports multiple logical streams per TCP connection at the protocol level, MCP protocols implement multiplexing entirely at the application layer - typically by tagging each message or chunk with a stream or session identifier.

This architecture provides the appearance of persistent, streamable communication while maintaining compatibility with HTTP infrastructure (load balancers, proxies, etc.), but also inherits limitations and security considerations from both HTTP/1.1 and the custom protocol layers.

‍

Persistent Connections

A cornerstone of streamable-HTTP design is the persistent connection: one socket, many messages. Connections may be kept open for the life of a client session, supporting:

• Continuous Data Flows: No need to reestablish connections for each message.
• Low Latency: Elimination of handshake and TCP slow-start for each operation.
• Scalability: Fewer concurrent sockets required, reducing resource overhead.

‍

Protocol Framing

MCP must impose its own framing on top of the raw stream, as TCP and HTTP/1.1 only provide a transport, not message boundaries. Common framing strategies include:

• Length-Prefix Framing: Each message is preceded by a length field indicating how many bytes follow.
• Delimiter-Based Framing: Messages are terminated by a specific byte or sequence (e.g., \r\n\r\n).
• Envelope Structures: Protocols may encapsulate messages in structured envelopes with headers, IDs, and checksums for integrity.

Framing is critical for correct parsing - but also introduces opportunities for confusion and exploitation if parsing is inconsistent or incomplete.

‍

Application-Layer Multiplexing and Logical Streams

Without protocol-level support, MCP multiplexing is implemented at the application layer. Typical methods include:

• Tags or IDs: Each message contains a field specifying its logical stream or context.
• In-Band Control Frames: Special messages can open, close, or reset logical streams within the persistent channel.
• Session Metadata: Stream IDs, authentication tokens, and other stateful markers travel alongside payloads within the MCP stream.

Multiplexing improves performance and resource usage but complicates security analysis, as payloads for different users or operations may be interleaved within the same persistent HTTP request.

‍

Session Management and Authentication

Persistent streams require careful handling of authentication and session state:

• In-Band Authentication: Clients may authenticate once and then send multiple requests over the same stream.
• Session Renewal: Long-lived sessions may need periodic renewal, increasing the window for exploitation if controls are weak.
• Context Propagation: Each message may need to carry context, making it vulnerable to injection, confusion, or hijacking.

‍

Implications for Security Analysis

These protocol traits make MCP/streamable-HTTP both powerful and risky. The flexibility and abstraction layers that enable multiplexed, real-time interaction also offer attackers more places to hide payloads, evade detection, or confuse stateful parsers.

‍

Security Implications of Streamable-HTTP

Expanded Attack Surface

Persistent connections mean an attacker has a much longer-lived conduit into a system. There is no natural "reset" between requests, allowing for:

• State Confusion: Manipulating protocol state across multiple messages.
• Incremental Attacks: Gradually building up a malicious payload over time.
• Session Hijacking: Exploiting weak authentication or context propagation.

‍

Invisibility to Traditional Tools

Most DAST (Dynamic Application Security Testing) tools are fundamentally built around the assumption of stateless request/response cycles. They expect to inject a payload, observe a response, and move on. Streamable-HTTP's persistent, multiplexed nature breaks this mental model:

• Interleaved Messages: Tools may miss the association between a payload and its ultimate effect.
• Fragmented Payloads: Exploits may be spread over multiple frames or logical streams.
• No Clear Response Boundaries: A payload might trigger an exploit several messages later, escaping detection.

‍

Where Payloads Can Hide

Attackers can exploit these features by:

• Hiding in Multiplexed Streams: Sending malicious data on a logical stream that’s only processed under certain conditions.
• Leveraging Fragmentation: Smuggling attack components over several frames, reassembled by the server.
• Manipulating Session State: Changing context mid-stream to escalate privileges or bypass checks.

These factors make MCP and streamable-HTTP an attractive and under-scrutinized target for determined adversaries.

‍

Vulnerabilities Enabled by Streamable-HTTP and MCP Design

Path Traversal in Streamed Payloads

Consider a scenario where a streamable-HTTP endpoint allows file operations, such as downloading or uploading files. A naive parser may only check file paths for malicious input at the boundary of each message, but attackers can use fragmentation or multiplexing to evade these checks.

Example:

• The client sends a file download request, but splits the "../" sequence (used for directory traversal) across two frames, bypassing a naive filter:
  • Frame 1: {"action": "get_file", "path": "/et
  • Frame 2: c/../passwd"}

The server, upon reconstructing the full path, processes /etc/../passwd and potentially exposes sensitive system files.

‍

Content Disclosure due to Boundary Confusion

Because multiple logical streams may coexist within the same physical channel, mistakes in stream ID handling can result in data leakage:

• Mix-ups: Data intended for one authenticated user may be routed to another if stream context is lost.
• Response Smuggling: An attacker opens several streams, causing the server to confuse responses, leading to information disclosure.

‍

Command and Code Execution via Injection

If the MCP server fails to sanitize inputs within persistent streams, classic injection attacks (command, SQL, deserialization) are possible - but with added persistence:

• Multi-Stage Payloads: Attackers can deliver a payload incrementally over several messages.
• Session-Scoped Exploitation: Once a vulnerability is triggered, the attacker may maintain access as long as the session remains active.

‍

State Confusion and Replay Attacks

Long-lived streams are vulnerable to state confusion:

• Replay Attacks: Captured frames from a valid session may be replayed on a new stream if session identifiers are not bound tightly to connection state.
• Interleaved Attacks: Malicious and benign messages mixed together may disrupt protocol parsing or lead to privilege escalation.

‍

Other Bug Classes: Desync, Overflow, Resource Starvation

• Desync: Overlapping or misaligned message boundaries can cause request/response confusion, especially when custom framing is implemented incorrectly.
• Buffer Overflows: Inadequate length checking in custom framing can lead to heap or stack overflows.
• Denial of Service: Attackers may deliberately fragment messages or open thousands of logical streams to exhaust server resources.

‍

Real-World Analogs

Protocols using similar patterns - such as custom streaming APIs - have suffered similar classes of bugs, often going undetected for years due to the mismatch between protocol complexity and available testing tools.

‍

Why Traditional Web Application Testing Fails

Mental Model Mismatch

Classic web application scanners treat each HTTP transaction as isolated and stateless. In a streamable-HTTP/MCP world, messages are persistent, contextual, and often multiplexed - breaking the assumptions of these tools.

Inability to Maintain Protocol State

• No Stream Awareness: Tools cannot track individual logical streams or the state machine underlying the protocol.
• Missed Injection Points: Payloads must be injected into the right stream, at the right time, with the right context. Classic tools have no way to target these.
• Response Tracking: Traditional tools cannot correlate asynchronous responses with injected payloads, leading to missed vulnerabilities.

‍

Signature-Based Detection Blind Spots

Most DAST/SAST tools look for telltale patterns in responses - error messages, reflected payloads, etc. With multiplexed, stateful communication, these signals are diluted or delayed, and attacks may succeed without any overt error.

‍

Real Impact: Case Study

A penetration test of a real-time trading platform using MCP revealed no issues when scanned with conventional tools. Only a manual, protocol-aware review discovered a critical path traversal vulnerability - one that, if exploited, could have enabled an attacker to extract trading strategies and customer data undetected.

‍

Enter Penzzer: Uncovering the Invisible with MCP Inspector

Recognizing the unique risks posed by MCP and streamable-HTTP servers, Penzzer’s research team developed the MCP Inspector - the first fuzzer and vulnerability scanner purpose-built for this environment.

Architectural Overview

• Deep Protocol Integration: MCP Inspector speaks streamable-HTTP natively, understanding framing, multiplexing, and context propagation.
• Session Tracking: Maintains full protocol state, tracking authentication, logical streams, and message boundaries in real time.
• Extensible Payload Engine: Supports custom fuzzing payloads for path traversal, injection, overflow, and more.

‍

Deep Traffic Parsing

Unlike conventional tools, MCP Inspector can:

• Reconstruct Fragmented Messages: Handles message fragmentation and reassembly, ensuring fuzzing payloads reach the server as intended.
• Follow Multiplexed Streams: Maintains a per-stream context, allowing for targeted attacks and accurate vulnerability attribution.
• Analyze In-Band Control Frames: Detects and manipulates protocol-specific control messages, probing for logic bugs and state confusion.

‍

Payload Delivery

• Precision Fuzzing: Injects payloads at arbitrary points within streams - start, middle, or end - emulating both naive and advanced attacker techniques.
• Timing Control: Varies inter-message timing to uncover race conditions and time-dependent bugs.
• Fragmented Attack Simulation: Delivers multi-stage payloads, mirroring real-world smuggling and obfuscation.

‍

Detection and Reporting

• Automated Exploit Identification: Monitors server responses for anomalies, unauthorized disclosures, or unintended behaviors.
• Context-Rich Alerts: Correlates each finding with protocol state, message history, and stream metadata - making triage and remediation straightforward.
• Seamless Integration: Exposes results via API and UI, supporting CI/CD integration and ongoing monitoring.

‍

Real-World Example

During a proof-of-concept engagement, Penzzer’s MCP Inspector uncovered a directory traversal vulnerability in a custom MCP server used for IoT device management. By requesting a file that was above the parent directory from which files should have been requested, a sensitive file /etc/shadow has been accessed on the server running the MCP server.

‍

Example directory traversal attack via MCP

POST /mcp/ HTTP/1.1
Host: server_ip_address:8000
Accept-Encoding: gzip, deflate
Connection: keep-alive
User-Agent: python-httpx/0.28.1
Accept: application/json, text/event-stream
content-type: application/json
mcp-session-id: 94898da8bd774249852522a945b380b6
mcp-protocol-version: 2025-06-18
Content-Length: 185

{"method":"tools/call","params":{"name":"read_row_csv_file","arguments":{"filename":"../../../../../../../../../etc/shadow","row":0},"_meta":{"progressToken":2}},"jsonrpc":"2.0","id":2}

HTTP/1.1 200 OK
date: Mon, 14 Jul 2025 09:56:15 GMT
cache-control: no-cache, no-transform
connection: keep-alive
content-type: text/event-stream
mcp-session-id: 94898da8bd774249852522a945b380b6
x-accel-buffering: no
transfer-encoding: chunked

event: message
data: {"jsonrpc":"2.0","id":2,"result":{"content":[{"type":"text","text":"root:$y$j9T$x.x.$x.x.x:19778:0:99999:7:::\nName: 0, dtype: object"}],"structuredContent":{"result":"root:$y$j9T$x.x.$x.x.x:19778:0:99999:7:::
\nName: 0, dtype: object"},"isError":false}}

NOTE: Some aspects of the /etc/shadow file have been redacted

Best Practices and Next Steps

Recommendations for MCP and Streamable-HTTP Environments

• Protocol-Aware Security Testing: Regularly test MCP and similar servers with tools that natively understand persistent, multiplexed streams.
• Input Validation: Enforce rigorous canonicalization and input filtering at the point of use, after reassembly.
• Session Management: Bind authentication and authorization tightly to both physical and logical streams; expire sessions promptly.
• Monitoring and Logging: Track activity at the stream and message level to detect abuse and anomalous patterns.
• Fuzz Early, Fuzz Often: Integrate protocol-aware fuzzing into development and deployment pipelines using tools like Penzzer's MCP Inspector.