PERMISSION/PROTOCOL
Back to incident tracker

2025-07-01

CriticalPrimary

mcp-remote OAuth Proxy: Malicious MCP Server Triggers Shell Metacharacter Injection via authorization_endpoint URL Leading to RCE (CVE-2025-6514, CVSS 9.6)

mcp-remote (437K+ downloads) OAuth proxy passed unsanitized authorization_endpoint URLs to shell commands during OAuth flow. A malicious MCP server could inject shell metacharacters via crafted authorization endpoint URL, achieving RCE on client machine. CVSS 9.6. Patched in v0.1.16.

mcp-remoteTool execution / MCPCommand injection via OAuth server-controlled URL parameterDeveloper workstation / mcp-remote OAuth proxy client

What happened

A malicious MCP server returned a crafted authorization_endpoint URL containing shell metacharacters in its OAuth metadata. When mcp-remote processed this URL during the OAuth flow, the metacharacters executed arbitrary shell commands on the developer's machine.

Why it matters

Full RCE on developer machines running mcp-remote: complete access to local files, credentials, environment variables, SSH keys, and API tokens. 437K+ downloads put a large number of developer environments at risk.

Missing authorization check

URLs from server-provided OAuth metadata are attacker-controlled and must be treated as untrusted input. URL values should never be interpolated into shell commands; use parameterized URL handling or spawn browser processes with argument arrays.

Would PP block it?

Requiring a PP receipt before connecting to a new MCP server (authorizing the OAuth flow initiation) gives developers an opportunity to review the server's legitimacy before the vulnerable code path runs.

Incident analysis

Timeline and technical read

Timeline

  1. 2025-07-01

    CVE-2025-6514 disclosed: mcp-remote passes malicious MCP server's authorization_endpoint URL to shell commands without sanitization, enabling RCE during OAuth flow. CVSS 9.6.

  2. 2025-07-01

    mcp-remote v0.1.16 released with fix: authorization_endpoint URLs are now sanitized before use in OAuth flow.

Technical breakdown

  • mcp-remote fetched server metadata including the authorization_endpoint URL from the remote MCP server.
  • This URL was interpolated directly into a shell command (e.g., to open a browser for the OAuth flow) without sanitization.
  • Shell metacharacters (`;`, `|`, `$()`) in the URL allowed the attacker to append arbitrary commands to the shell invocation.
  • The attack is triggered during normal OAuth flow — expected user interaction, not a separate attack step.

Authorization boundary

Where the authorization boundary should have been

This incident is categorized as Tool execution / MCP. The relevant Permission Protocol gate is Runtime Gate. The read is conditional: the block only applies where the real action boundary is routed through a gate.

If enforced at
MCP server connection authorization, OAuth flow initiation
Still needs
Server-controlled URL parameter interpolated into shell; no input sanitization in OAuth handler
Receipt required for
Connecting to new MCP servers, initiating OAuth authorization flows

PP's Runtime Gate would require receipts before OAuth flows initiate with new MCP servers. It would not prevent shell injection within mcp-remote's internal OAuth handling — that requires the code-level fix (parameterized execution).

Start small

Put the relevant gate at this action boundary.

This incident maps to Runtime Gate. Start with the boundary that controls the actual action, then require a signed receipt before execution.

Replay this incident with a signer in the loop