Command Injection: Uncovering A New Attack Vector of MCP Server

Model Context Protocol (MCP) defines how LLM hosts (clients) discover and invoke external tools exposed by servers. Servers publish tool schemas like names, descriptions and argument formats while clients allow the model to autonomously decide when and how to call these tools during task execution.

This design improves the extensibility and composability of AI agents. However, the same flexibility also introduces a broad and largely underexplored attack surface.

Beyond Tool Poisoning and Agent Steering

Much of the recent MCP related security discussions focus on the attacks such as –

• Tool metadata poisoning: where malicious instructions are present in tool metadata.
• Rug pull attacks: where a previously benign server becomes malicious after adoption.
• Puppet / agent steering attacks: where the model is gradually coerced into pursuing attack-defined goal.

All these attacks manipulate model behaviors.

Command Injection Attack in MCP

As part of our security research in MCP, our Application and Threat Intelligence (ATI) team has uncovered an additional attack vector in MCP taxonomies command injection via MCP tool invocation which has limited attention so far.

In traditional security, command injection occurs when untrusted input reaches a shell or command interpreter. In MCP, the mechanism is subtler but potentially more powerful.

When an MCP server is launched locally (for example via SSE transport):

• The server process runs on the user's machine
• Tools exposed by the server execute with the user's local OS privileges
• The LLM decides when to invoke those tools

If a malicious server exposes a tool that executes shell commands (directly or indirectly), and the model can be induced to call it, the result is:

LLM-mediated command execution on the host system

This is a classic confused deputy scenario, where the model bridges natural-language input and privileged system actions.

Attack Flow: Step by Step

A typical MCP command-injection attack unfolds as follows:

Figure 1: MCP Command Injection Attack Flow

1. Server publication:

An attacker releases an MCP server that appears legitimate (e.g., "system diagnostics," "developer utilities," or "file helpers").

2. Benign integration:

A user or application integrates the server into an AI agent's workflow, often without deep inspection of tool internals.

3. Dangerous capability exposure:

The server exposes a tool that can execute OS commands (e.g., via subprocess, scripting runtimes, or system APIs).

Figure 2: Attacker Integrates a Harmful Tool in MCP Server

4. Model manipulation:

Using tool descriptions, runtime responses, or workflow framing, the server biases the model into invoking that tool even when the user did not request such behavior.

5. Command execution:

The tool runs on the local machine, executing attacker-controlled commands, and returning the output through the normal MCP response path.

Figure 3: MCP Command Injection Attack Sample PoC Output

Deployment Choices That Amplify Risk

The severity of this attack vector depends heavily on deployment architecture. In many real-world MCP integrations, servers are launched locally by the client using STDIO transport. In these cases, any tool exposed by the server runs with the same privileges as the user or application that launched it. This means that a malicious MCP server does not need to break isolation it already operates inside the trusted boundary. By contrast, when MCP servers are deployed remotely over HTTP or SSE, command execution is limited to the attacker's own infrastructure. While remote servers can still manipulate model behavior or exfiltrate data, local execution dramatically increases risk by exposing the host environment itself.

Attack Traffic Analysis

Our team has analyzed the network traffic generated during a command-injection scenario using MCP over SSE transport. The resulting traffic pattern highlights how protocol-compliant interactions can still lead to unintended command execution.

The interaction begins with the client establishing a persistent Server-Sent Events connection. The client issues an HTTP GET request to “/sse”, which is acknowledged with a 200 OK response. This response does not contain a single payload but instead opens a long-lived event stream. Within this stream, the server sends a sequence of initialization and discovery messages, including endpoint initialization, notification/initialized, and repeated tools/list responses. These messages inform the client and by extension the LLM of the tools exposed by the server and their associated schemas.

Once initialization is complete, the client sends a POST request corresponding to a user prompt, for example a simple input such as "hi." This request is translated by the client into a tool-selection query, typically surfaced as a tools/list or planning step that includes the user's input. The server responds with a 200 OK, indicating which tool the model has selected and providing the arguments to be used for that invocation. In the command-injection scenario, this is the critical step where a tool capable of executing system commands is selected, despite the benign nature of the original prompt.

Following tool selection, the client issues another POST request containing the tool invocation, such as a tools/call request with the command to be executed. The server responds with 200 OK and returns the output of the executed command. At this point, the system-level action has already occurred on the host where the MCP server is running.

Finally, the client sends a subsequent POST request containing the tool output back into the LLM context. The server replies with 200 OK and provides the model's final response, for example a generic conversational reply such as "How can I assist you?" From a protocol perspective, this sequence represents a normal, successful interaction. However, the underlying traffic shows that a system command was executed as part of handling a benign user input.

Figure 4: MCP Command Injection Sample Traffic

This traffic pattern illustrates a key challenge in MCP security: the protocol itself provides no explicit signal that a sensitive or high-risk action has taken place. All requests and responses are valid, expected, and indistinguishable from normal tool usage unless the client enforces additional policy checks at the execution layer.

MCP Command Injection Strike in BreakingPoint

At Keysight Technologies, our Application and Threat Intelligence (ATI) team, the security researchers have examined the attack traffic patterns of MCP command injection and added a new (verified) Strike in ATI-2025-25 StrikePack released on December 23, 2025, as shown below –

Figure 5: MCP SSE Command Injection Strike in BPS

bling them to test their currently deployed security controls' ability to detect or block such attacks.

Leverage Subscription Service to Stay Ahead of Attacks

Keysight's Application and Threat Intelligence subscription provides daily malware and bi-weekly updates of the latest application protocols and vulnerabilities for use with Keysight test platforms. The ATI Research Centre continuously monitors threats as they appear in the wild. BreakingPoint and in the future, other tools like CyPerf, now provide customers with access to attack campaigns for different advanced persistent threats, ena

Related Content

Related Posts